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PREFACE 


he  Department  of  Defense  (DoD)  High  Order  Language  (HOL)  Program  has  as  a 
primary  objective  to  establish  a minimum  number  of  HOLs  for  use  throughout  DoD. 
This  volume,  containing  comparisons  of: 
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against  the  DoD  language  requirements  document  'Tinman,  ^ represents  Computer 
Sciences  Corporation's  contribution  to  DoD's  goal.  /This  work  was  performed  under 
contract  N00039-75-C-0289  and  was  monitored  by  Mr.  Robert  I.  Kahane  (ELEX  03E) 

Washington,  D.  C.  \ 
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SECTION  I - INTRODUCTION 


Like  most  large  computer  users,  the  Department  of  Defense  (DoD)  has  been  plagued 
with  a proliferation  of  High  Order  Languages  (HOL)  and  Incompatible  systems  serving 
the  "same"  language.  The  DoD's  problems  are,  in  principle,  no  different  from  the 
rest  of  the  computer  user  community;  they  are  simply  larger  as  is  the  use  of  com- 
puters. Further,  DoD  systems  are  often  individually  very  large  and  very  long  lived. 
Because  of  the  intimate  integration  of  the  computer  resources  with  the  rest  of  a large 
defense  system,  it  has  not  been  possible  to  change  computer  subsystems  with  the 
frequency  which  might  characterize  a commercial  operation.  As  a result,  maintenance 
of  the  computer  system  is  both  long-term  and  dynamic,  and  maintenance  in  many  cases 
involves  modification  of  the  system  to  respond  to  new  threats.  Defense  systems  are 
often  composed  of  interacting  but  independently  developed  subsystems,  sometimes 
brought  into  existence  over  a period  of  years,  all  of  which  must  be  served  by  a com- 
mon but  evolving  hardware  base.  In  such  an  environment,  the  DoD  finds  itself  spend- 
ing an  increasingly  larger  fraction  of  its  systems  resources  on  software.  HOL  com- 
monality and  the  resulting  flexibility  would  provide  a powerful  tool  for  reducing  the 
high  cost  of  software  in  DoD. 

With  each  of  the  Military  Departments  studying  the  problem  and  making  proposals  for 
common  languages,  it  was  clear  that  the  greatest  benefit  could  be  reaped  by  providing 
languages  common  across  the  DoD.  In  January  of  1975,  a DoD  High  Order  Language 

Working  Group  (HOLWG)  was  chartered  by  DDR&E  with  representatives  from  the 

} 

Military  Departments  to  investigate  the  requirements  and  specifications  for  program- 
ming language  commonality,  to  compare  these  with  existing  approaches,  and  to  recom- 
mend adoption  or  implementation  of  the  necessary  common  languages  or  approaches. 
Until  the  matter  is  resolved,  the  DoD  will  not  support  the  further  implementation  of 
new  HOL  in  R&D  programs. 

The  first  task  of  the  HOLWG  was  to  formulate  a set  of  requirements  consistent  with 
the  levies  of  the  Military  Departments.  Requirements  were  solicited  from  as  broad 
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a base  as  possible,  to  be  prioritized  later  as  required.  Inquiries  were  not  restricted 
to  those  programs  presently  using  HOLs;  rather,  a major  thrust  of  the  effort  was  to 
provide  HOLs  to  meet  the  requirements  of  those  who  are  now  constrained  to  use  an 
assembly  language  for  lack  of  a suitable  HOL. 

It  has  been  impossible  to  define  rigorously  the  exact  level  requirements  desired; 
therefore,  a "Strawman"  of  preliminary  requirements  was  established  to  define  this 
level  by  illustration.  The  "Strawman"  was  not  intended  to  be  complete  or  consistent, 
rather  it  was  deliberately  provocative  to  elicit  the  widest  possible  comment.  It  was 
forwarded  to  the  Military  Departments,  and  by  them  to  their  various  operating 
agencies.  In  addition,  it  was  distributed  to  other  Government  agencies,  the  academic 
community,  and  industry;  through  industry  organizations  and  military  contractors; 
and  by  direct  inquiry.  A number  of  individuals  and  organizations  have  had  an  oppor- 
tunity to  examine  this  document  and  provide  inputs.  The  bulk  of  such  comments  were 
positive  and  useful. 

The  results  of  four  months  of  such  input  were  put  together  in  a more  concrete  form; 
one  which  could  then  be  representative  of  a fairly  complete  set  of  requirements,  although 
still  a tentative  set.  This  document  was  called  the  "Woodenman, " and  it  too  was  distrib- 
uted widely.  It  provided  a more  rigorous  framework  for  specific  comments.  On  the 
basis  of  all  inputs  and  the  official  responses  from  each  of  the  Military  Departments, 
a more  complete  set  of  requirements  has  evolved  and  is  called  "Tinman. " This 
document  represents  a set  of  requirements  for  HOL  computer  programming  language 
consistent  with  the  input  from  the  Military  Departments. 

The  next  task  of  the  HOLWG  was  an  investigation  and  comparison  of  existing  HOLs 
to  the  DoD  HOLWG's  language  requirement  document,  "Tinman. " 

A candidate  set  of  HOLs  were  chosen  and  contracted  to  various  industry,  individual, 
and  university  groups  for  evaluation.  The  effort  represented  by  this  volume,  is 
Computer  Sciences  Corporation's  contribution  to  the  task  of  establishing  a minimum 
number  of  HOLs  for  use  throughout  DoD.  Each  contractor  investigated  and  compared 
selected  languages  to  the  DoD  HOLWGs  language  requirement  document  "Set  of  Criteria 
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and  Needed  CharsictorlntlCH  for  a Common  DoD  High  Order  Language,  Tinman." 
Specifically,  each  contractor  performed  the  following  tasks: 

(1)  For  each  language  characteristic  listed  in  "Tinman,"  the  contractor  will 
determine  the  "degree"  of  compliance  of  each  of  the  candidate  languages. 

(a)  If  the  requirement  is  "met, " the  contractor  will  demonstrate  how 
this  is  so  (e.g. , the  presence  or  absence  of  a particular  feature, 
computer  program,  etc. ).  Additionally,  the  contractor  must  show 
that  this  solution  does  not  conflict  with  any  other  DoD  HOL  require- 
ment. 

(b)  For  requirements  which  are  "not  met"  or  only  partially  met,  the 
contractor  will  provide: 

1.  An  analysis  of  why  the  language  does  not  fulfill  or  only  partially 
fulfills  the  requirement. 

2.  The  scope  of  modifications  that  would  be  necessary  to  bring  a 
language  into  compliance,  and  their  impact  on  other  language 
features. 

3.  The  impact  of  such  modifications  on  implementations 

(c)  If  the  requirement  is  such  that  is  is  not  addressed  in  the  provided 
language  documentation  (e.  g. , the  requirement  is  strictly  dependent 
on  the  operating  system,  libraries  or  is  only  a management  consider- 
ation), then  the  contractor  will  so  indicate. 

(2)  Upon  completion  of  (1)  the  contractor  will  then  identify  features  of  the 
language  which  are  not  needed  to  satisfy  the  requirements  with  his  recom- 
mendation as  to  whether  those  features  should  be  kept  or  possibly  eliminated. 
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Introduction 


The  followina  is  a collection  of  recommendations  for  improvements 
in  the  Tinman  reouirements.  The  comments  do  not  address  questions  of 
interpretation  or  obvious  omissions  or  wording  problems,  except  where 
sjch  omissions  or  problems  cause  the  intent  of  a Tinman  requirement  to 
be  unclear. 

This  report  has  one  section  on  the  Tinman  as  a whole,  and  a number 
of  sections  on  individual  requirements.  Not  all  of  the  requirements  ar» 
commented  on,  many  of  them  beinq  so  clearly  reflections  of  currently 
accepted  language  design  philosophy  that  no  comment  is  needed. 

The  version  of  the  Tinman  requirements  addressed  in  this  report  is 
the  one  dated  June,  1976. 

The  following  comments  and  criticisms  are  intended  constructively, 
we  trust  that  they  will  be  received  in  that  way. 
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TIN1AU 

General  Comments 


i 1 


The  principal  criticism  of  Tinman  as  a whole  is  that  it  nee^s  to  be 
more  carefully  written.  We  say  this  while  recognizing  that  it  obviously 
has  received  a great  deal  nf  care  a"d  work.  However,  adherence  to  * fer- 
rules (which  are,  unf ortunate  ly , very  laborious  to  follow)  will  result 
in  the  next  version  being  much  easier  to  understand.  They  are:  (1)  «e 
certain  that  all  terms  are  clearly  understood.  (2)  Use  ter^s 
consistently.  (t)  Avoid  usina  slight  variations  of  terminology  for 
reasons  of  style.  The  followino  paraaraphs  are  short  elaborations  of 
these  points.  If  any  of  the  authors  of  Tinman  find  them  to  he  so 
elementary  as  to  be  insultino,  we  apologize,  but  we  thirk  that  the 
points  should  be  made. 

Assuring  that  all  terms  are  clearly  understood  is  quite  difficult 
in  a document  of  the  nature  of  Tinman,  because  the  simple  exredient  of 
defining  all  terms  is  net  available.  For  example,  it  is  clear  that  the 
authors  of  Tinman  intended  for  the  concept  of  type  to  be  defined 
implicitly.  In  most  cases,  however,  explicit  definition  is  appropriate. 
In  requirement  P2  the  word  equivalence  is  used.  In  mathematics  this 
word  must  be  defined  in  each  context,  but  no  definition  is  given  in 
Tinman  and,  as  a result  exactly  wh.it  was  intended  in  this  requirement  is 
not  clear.  In  addition,  there  are  a number  of  computer  terms  which  the 
authors  apparently  thought  would  be  clear  to  any  professionals  in  the 
fiela,  but  which  are  open  to  interpretation  (c.g.,  conformable  arrays  in 
requirement  B7  and  free  union  in  requirement  E7). 

The  inconsistent  use  of  terms  is  universally  recognized  as 
something  to  be  avoided,  but  it  is  very  difficult  to  do  without  some 
sort  of  mechanical  assist,  such  es  a kwic  index.  Even  with  such  an 
assist  the  job  is  tiresome.  In  requirement  D5  it  appears  that  the  word 
range  is  being  used  in  the  sense  of  "set  of",  a meaning  different  from 
that  used  elsewhere  in  Tinman.  The  result  is  uncertainty  as  to  the 
exact  intent  of  this  requirement. 
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Requirement  A2 

we  maintain  that  a bit  strinq  type  is  necessary  (see  the  comments 
on  BIO). 

Tt  is  not  clear  from  the  statement  of  this  requirement  if  literally 
a character  type  is  beinq  called  for  or  if  character  type  is  an  ellipsis 
fcr  character  string  type.  Given  a cfaracter  type  and  the  definitional 
mechanisms  called  for  in  the  Tinman,  the  common  character  strinq 
capabilities  can  be  achieved.  W'e  believe,  however,  that  the  character 
strinq  type  is  useful  enouqh  to  warrant  its  inclusion  as  a 
compiler-defined  type.  Full-blown  variable  length  strings  are  probably 
not  needed.  For  most  applications  variable  length  strings  with  maximum 
lengths  known  at  comnile  time  suffice.  Indeed,  for  most  application 
strinqs  with  fixed  lenath  (fixed  at  compile  time)  are  probably  adequate. 

we  are  confused  by  the  mention  of  some  type  generators  in  both 
requirements  A 2 and  F6.  If  this  was  intentional,  then  we  have  missed 
the  point.  It  appears  that  requirement  A2  should  call  for  the  "basic" 
types  (inteqer,  real.  Boolean,  character,  character  string,  and  bit 
string)  and  requirement  Eft  should  cover  the  type  generators  (records, 
arrays,  enumeration  types,  and  powersets). 


Reouirement  A4 

To  treat  fixed  point  numbers  as  exact  ouantities  often  results  in  a 
great  deal  of  run-time  overhead.  Usually  multiple  precision  integer 
arithmetic  is  involved.  If  the  fixed  point  capability  is  elaborate 
enouqh,  full-blown  multiple  precision  rational  arithmetic  could  be 
necessary.  Based  on  CSC's  experience  with  Navy  embedded  computer 
systems  (for  example,  NTDS),  it  is  doubtful  that  the  user  community 
would  accept  such  overhead. 

Based  on  this  same  experience,  we  think  that  something  slightly 
different  is  intended:  Whenever  two  fixed  point  quantities  are  added  or 
subtracted,  any  shifting  necessary  to  line  up  radix  points  must  he  left 
shifts.  That  is,  the  usual  floatino  point  discipline  of  a right  shift 
of  one  operand,  discarding  bits  which  correspond  to  "invisible"  error 
bits  of  the  other  operand,  is  unacceptable;  the  other  operand  is 
considered  not  to  have  any  "invisible"  error  hits  — it  is  exact.  CMS-2 
compilers  perform  their  fixed  point  additions  and  subtractions  in  this 
manner  for  precisely  this  reason,  and  at  the  strong  insistence  of  their 
user  community. 


Reouirement  A5 


It  is 
character 


not  clear  if  this  requirement 
sets  or  collating  sequences 


is  tor  an  ability  to  specify 
— two  quite  distinct  concepts. 
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Poth  of  these  concepts  are  also  distinct  fro*  that  cf  an  enumeration 
type,  so  to  be  able  to  specify  either  using  the  notation  of  enumeration 
types  is  a conflict  with  requirement  H10- 

The  remainder  of  our  comments  are  based  on  the  assumption  that  the 
subject  is  character  sets. 

In  our  view,  the  character  set  used  is  a property  of  the  internal 
representation  of  the  value,  not  of  the  value  itself  or  of  the 
operations  available  for  it.  Hence  a character  set  is  not  a tyie,  inj 
which  set  is  used  depends  on  the  containing  variable  (see  also  the 
comments  on  B1 ) . If  two  character  or  character  strinq  variables  nave 
different  representation  --  different  character  sets  --  then  implicit, 
automatic  conversion  should  occur  when  the  value  of  one  is  copied  to  the 
other.  Conversion  mioht  not  alwavs  be  possible,  because  a character  may 
appear  in  only  one  of  the  character  sets,  but  the  same  is  true  for 
numeric  variables  having  aifferent  ranges,  and  the  Tinman  explicitly 
prohibits  ranqes  from  determining  types  (requirement  r>4).  Explicit 
character  set  conversion  operators  are  probably  needed  also,  especially 
for  literal  values. 


Requirement  Aft 

Why  must  the  lower  subscript  bound  be  determinable  at  compile 
time?  If  the  user  really  needs  a dynamic  lower  bound,  this  rule  must 
make  his  code  more  awkward,  harder  to  read,  and  a bit  harder  to 
optimi ze. 

The  statement  that  the  default  lower  bound  (our  interpretation  of 
preferable  lower  bound)  is  zero  is  arguable,  particularly  whpr  one  of 
the  justifications  is  that  it  contributes  to  clarity.  The  qreat 
majority  of  applications  of  arrays  are  "natural"  ones  --  those  which 
have  a concept  of  a first  element,  a second  element,  etc.,  and  a last 
element,  and  these  should  be  represented  by  1,  2,  ...,  and  the  array 
size,  not  0,  1,  and  one  less  than  the  array  size.  Arrays  which  have  a 
lower  subscript  bound  different  from  T arise,  for  the  most  part,  from 
specialized  mathematical  formulas,  which  probably  play  a very  minor  rol* 
in  embedded  computer  applications  in  the  Department  of  Defense. 

Even  the  requirement  that  the  values  be  contiquous  might  be  unduly 
harsh.  It  is  simple  to  implement  non-ccnt ipuous  subscript  values 
without  the  expense  of  qarbaqe  collection;  the  compiler  can  simply 
construct  a mapping  function,  which  a programmer  who  needs  such  a 
capability  would  otherwise  have  to  do  himself.  Requirement  J1  prohibits 
this  general  case  from  affecting  the  efficiency  of  the  oroinary, 
contiguous  subscript,  case.  The  only  question,  of  course,  is  whether 
there  is  enouoh  need  to  justify  the  inclusion  of  such  a feature. 
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1 Reguirement  92 


Reouirement  B2 

The  text  of  this  requirement  contains  the  sentence:  "For  floating 
point  numbers  identity  will  be  defined  as  the  same  within  the  stecified 
(minimum)  precision."  This  cannot  be  done  efficiently  on  binary 
machines,  assuminq  that  the  precision  specification  is  stated  in 
decimal.  Furthermore,  ianorina  any  auestions  of  efficiency,  to  build 
such  a predicate  into  a language  is  dangerous  because  it  would  tend  to 
encourage  programmers  to  gloss  over  the  difficulties  of  working  with 
floating  point  data.  The  initial  accuracy  of  floating  point  data  is 
only  one  cons ider at  ion  when  a comparison  for  equality  is  performed,  and 
if  may  not  even  be  the  most  important.  The  build-up  of  error  in 
intermediate  calculations  must  be  taken  into  account,  usually  in  an  ad 
hoc  fashion  in  each  use. 


Requirement  B5 

Avoiding  truncation  of  the  most  significant  digits  implies  run  time 
checks.  We  recommend  that  the  programmer  be  able  to  avoid  this  overhead 
(see  also  the  comments  on  F7). 


Reauirement  BF> 

This  requirement  specifies  that  "and"  and  "or"  on  scalars  will  be 
evaluated  in  short  circuit  mode.  The  intent  of  the  Qualification  on 
scalars  is  unclear. 

In  addition,  specification  of  short  circuit  mode  conflicts  directly 
with  Requirement  Cl.  We  believe  that  short  circuit  mode  evaluation,  if 
provided,  requires  special  syntax.  It  is  hard  to  see  how  the  qiven 
example  improves  clarity  and  maintainability.  Dependencies  should  be 
clearly  shown;  for  example: 

if  I < 7 then  A(l)  > x else  false 
or  (using  our  own  syntax) 

if  I < 7 (and  A(l)  > X). 

A maintenance  programmer  cannot  miss  the  intent  here,  as  he  easily  can 
ii  a simple  Boolean  expression  is  used. 

Hence  we  recommend  that  the  second  sentence  of  the  requirement  be 
replaced  by: 

Short  circuit  mode  evaluation  will  be  guaranteed 
only  if  special  syntax,  clearly  showing  the 
dependencies,  is  used.  Otherwise,  the  programmer 
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TINMAN 

Requirement  6 6 


Mill  not  he  able  to  count  on  short  circuit  mode 
evaluation,  or  to  assume  that  it  Mill  not  occur. 

The  last  clause  of  course  means  that  the  programmer  can  not  depend  on 
every  function  in  an  expression  actually  being  called.  If  a function 
must  be  called,  it  can  be  nut  into  a separate  statement. 


Requirement  B8 

This  requirement  does  not  explicitly  forbid  "mixed-mode" 
arithmetic,  although  that  seems  to  be  in  the  spirit  of  the  requirement. 
"Mixed-mode"  can  be  defined  without  resorting  to  implicit  conversions  by 
defining  the  arithmetic  operators  to  depend  on  the  tyre  of  their 
operands  as  well  as  their  values.  Of  course,  everyone  knows  that  an 
implicit  conversion  is  performed  prior  to  execution  of  the  operation, 
but  if  the  conversion  is  done  by  the  firmware  it  becomes  difficult  to 
argue  that  anythinq  shady  is  qoina  on.  If  a prohibition  is  intended,  it 
should  be  explicitly  stated. 

with  regard  to  the  question  of  Mhether  or  not  "mixed-mode" 
arithmetic  should  be  prohibited,  it  becomes  difficult  to  argue  against 
Mhen  no  information  is  lost  during  the  conversion;  for  example,  when  an 
integer  value  is  converted  to  fixed  point  or  floating  point,  a fixed 
point  value  is  converted  to  floating  point,  or  a value  of  som«»  type 
representing  a real  number  is  converted  to  the  equivalent  complex 
number.  Indeed,  many  language  which  have  fairly  strict  type-check ina 
allow  something  like  this  for  constants  at  least  through  the  device  of 
specifying  numeric  constants  to  be  typeless,  specifying  only  a value 
not  a type.  It  is  probably  best  to  specify  that  those  conversions  which 
do  not  lose  any  information  (spelled  out  in  detail,  of  course)  can  be 
performed  implicitly. 

If  multiple  character  sets  are  to  be  supported,  as  indicated  by 
requirement  A5,  the  question  of  implicit  conversion  between  character 
sets  should  be  addressed.  Again,  such  conversions  should  probably  be 
permitted  in  any  case  in  which  no  loss  of  information  can  occur. 

many  programmers  find  conversions  between  integer  and  Boolean  and 
between  enumeration  types  and  integers  useful.  We  recommend  that  they 
be  included. 


Requirement  MO 


We  recommend  that  something  analogous  to  the  FORTRAN 
FORMAT-controlled  conversion  also  be  required,  both  for  I/O  and  internal 
conversions.  In  addition,  we  recommend  that  it  be  possible  to  cooy  a 
binary  bit  atring  into  a variable  of  any  type  and  vice  versa.  TMs  too 
would  he  provided  not  only  for  I/O  — that  is,  it  should  be  possible  to 
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Requirement  BIO 


move  a value  of  type  bit  string  into  any  variable,  without  type 
conversion,  and  vice  versa.  This  is  sometimes  the  only  efficient  way  to 
move  data  between  machines,  and  may  be  the  only  way  to  break  apart 
values  whose  structure  and  tyre  is  dynamically  determined.  It  is,  of 
course,  machine  and  representation  dependent,  and  allows  escape  from 
type  checking.  Requirement  J3  states  that  machine  dependence  shall  be 
oossible.  Type  consistency  rules,  in  our  view,  should  not  be  regarded 
as  a system  of  laws  that  the  programmer  cannot  violate.  Instead,  they 
are  a way  of  using  redundancy  to  ensure  that  the  programmer  means  what 
he  writes.  However,  the  programmer  knows  more  than  the  compiler,  and 
may  not  always  be  able  to  stay  within  the  constraints  laid  down  — he 
must  be  allowed  to  violate  them,  if  he  states  clearly  that  such  is  his 
intent.  This  is  analogous  to  providing  structured  programming  control 
structures,  but  keeping  the  goto  for  use  where  necessary  (see  the 
comments  on  G2). 


Reouirement  Cl 

To  write  two  function  references,  with  both  of  the  functions  having 
side  effects,  and  then  expect  the  side  effects  to  occur  in  a specific 
order  is  a terrible  programming  practice.  Yet  the  effect  of  this 
requirement  will  be  to  give  it  an  aura  of  legitimacy. 

Also,  in  practice,  this  rule  restricts  optimization  quite  a bit. 
Furthermore,  the  meaning  is  not  clear  for  some  cases  (e.g.,  embedded 
assignment).  A better  requirement  would  be: 

"There  shall  be  no  rule  in  the  language  specifying 
that  every  argument  of  an  expression  is  to  be 
evaluated  when  the  expression  is  evaluated,  nor 
makinq  the  value  of  an  expression  dependent  on  the 
order  of  evaluation  of  its  arguments,  except  where 
such  dependency  is  clearly  specified  as  part  of  the 
definition  of  an  operator." 

This  rule  can  even  be  enforced  by  the  compiler,  in  one  sense,  by  having 
it  generate  "side-effect  prone"  operands  (function  references,  embedded 
assignments,  etc.)  in  a random  order,  using  as  its  randomizer  some  datum 
over  which  the  programmer  has  no  control  (e.g.,  some  low-order  bit  of 
the  hardware  clock),  which  would  presumably  bring  out  any  incorrect 
dependency  on  the  order  of  occurrence  of  side  effects  early  in  the 
debugging  stage.  We  know  of  no  compiler  which  has  used  such  a 
technique  . 


Requirement  C? 

"Few  levels"  should  be  more  precisely  defined.  One  level,  as  in 
API,  seems  plainly  to  few.  wirth  now  believes  that  even  Pascal  has  too 
few  levels. 
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Requirement  D? 

The  requirements  speller)  out  here  are  good,  in  spite  of  any 
possible  disagreements  from  compiler  writers.  Another  one  needs  to  be 
added:  Alternative  literal  forms  for  the  same  quantity  will  have  the 
same  value.  For  example  (usino  FORTRAN  notation),  a comparison  of  1.1 
and  0.11E1  should  always  oive  an  ecual  result.  Some  compiler  writers 
mioht  well  complain  about  this  too. 


Requirement  D3 


Some  comment  should  be  made  about  the  initialization  of  variables 
shared  between  independently  compiled  programs  — e.g.,  in  COMMON,  we 
believe  that  for  any  named  block  of  such  variables,  ini t i a l i ration 
should  be  specified  in  no  more  than  one  place,  or  that  identical 
initialization  must  be  specified  in  all  declarations  (to  permit  cooying 
of  dec  larat ions) . 


Requirement  06 

Our  comments  on  this  recuirement  are  contained  in  the  paper  "A  Note 
on  'Pointers'"  by  Christopher  Earnest  (September  1,  1976),  presented  at 
the  Cornell  conference. 


Reonirement  PI 

The  need  to  he  able  to  define  new  data  types  is  clear.  However,  at 
the  risk  of  beino  thounht  unfashionable,  we  maintain  that  new  data 
operations  should  not  be  definable  in  the  language,  except  by  means  of 
procedures  and  functions.  In  other  words,  new  infix  operators  are 
neither  necessary  nor  desirable,  tor  the  following  reasons: 

(1)  H?  precludes  the  definition  of  new  precedence  levels,  and  we  agree 

— too  many  levels  is  contusing.  Rut  this  means  that  a new  infix 

operator  must  be  at  the  same  precedence  level  as  an  existing 

operator,  which  can  also  lead  to  distortion,  and  which  means  that 
new  operators  are  clearly  different  from  built-in  ones.  The 
problem  goes  away  if  new  infix  operators  are  not  allowed; 
functional  notation  specifies  precedence  clearly. 

(2)  If  new  symbols  are  introduced  as  operators,  then  very  soon  the  APL 
problem  of  overpunchinn,  etc.,  arises  --  thet  is,  the  primitive 
alphabet  becomes  too  large  for  ready  comprehension.  If  woror  are 
used  as  new  operators,  prehaps  enclosed  in  special  brackets,  rh«n 
what  is  the  »dvantaoe  over  function  notation? 
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(3)  The  requirement  for  comoonent  by  component  operations  (R7)  means 
that  the  most  natural  way  of  introducing  new  operators  --  as  new 
meaninqs  for  existing  operators  ~ is  often  not  possible.  matrix 
multiplication,  for  example,  must  be  expressed  by  means  of  a new 
operator  (as  it  is  in  APL).  Again  the  advantage  over  functional 
notation  is  unclear. 

(A)  Too  many  operators  makes  a language  very  unreadable,  in  our  view 
and  in  Dijkstra's  view  also.  He  has  strongly  criticized  APL  for 
exactly  this,  more  generally,  he  emphasizes  the  need  to  restrict, 
rather  than  to  expand,  the  basic  tools  we  work  with,  and  we  concur 
wholeheartedly.  Addition  of  new  operators  to  a languaqe  should  not 
he  easv;  making  it  so  invites  abuse. 

more  philosophically,  we  would  arnue  that  a lanouage  is  best 
extended  through  its  literature  (i.e.,  for  a programming  lanouage, 
through  its  programs),  in  which  existing  basis  elements  are  combined  in 
new  ways.  This  is  certainly  true  of  natural  languages:  New  words  are 
introduced  very  rarely,  and  new  meanings  for  existing  verbs  (the 
operators  of  the  language)  almost  as  rarely. 

we  believe  that  the  set  of  operators  which  deserve  to  be  generic 
arows  slowly.  The  basic  set  of  operators  should  probably  include  more 
than  the  Tinman  requires  — for  example,  matrix  operations  and  complex 
arithmetic  --  and  subsets  of  the  operators  should  be  defined  to  be 
supported  by  different  level  compilers.  Then  before  a new  ooerator  is 
introduced,  the  need  should  be  clearly  demonstrated,  and  if  warranted, 
the  compilers  and  the  languaae  documentation  would  he  modified  to 
support  it.  Such  additions  should  happen  rarely,  and  implementation 
through  the  compiler  often  leads  to  greater  efficiency.  If  someone  does 
not  understand  enough  about  the  structure  of  a language  to  understand 
its  compiler,  should  he  in  fact  be  able  to  modify  the  language? 

These  comments  do  not  apply  to  new  types  or  new  data  structures. 
These  can  be  thought  of  as  adjectives  applied  to  a noun  to  restrict  its 
scope,  or  as  strings  of  nouns,  embodying  additional  attributes.  in 
other  words,  the  languaqe  must  be  able  to  deal  with  new  kinds  of 
objects.  The  above  comments  dr  apply  to  the  introduction  of  new  ways  of 
defining  data  structures,  and  here  we  and  the  Tinman  seem  to  agree. 

It  is  of  course  necessary  to  be  able  to  do  something  with  new 
types,  and  new  data  structures.  The  only  way  to  introduce  new  scalar 
types  is  by  enumeration,  and  all  enumeration  types  share  a common  set  of 
operations.  The  interesting  cases  are  new  structured  types.  The 
structure-defining  mechanisms  must  include  qeneric  specification  of  the 
way  in  which  individual  components  of  a structure  can  be  referenced  and 
modified;  for  example,  all  array  types  have  the  same  access  conventions, 
whether  their  members  are  real,  integer,  or  themselves  structured.  It 
is  also  possible  to  define  qeneric  rules  for  the  meaning  of  relational 
operators  with  a new  ordered  type;  if  these  are  not  sufficient, 
functions  can  be  used.  In  some  cases,  reference  to  or  modification  of  a 
variable  should  have  side  effect*  — for  both  built-in  and  new  types. 
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The  Tinman  appears  to  partially  share  these  views  — Poolean  could 
he  provided  as  an  enumeration  type,  with  sufficient  definition  of  new 
operators.  The  fact  that  it  is  specified  explicitly  as  a built-in  type 
seems  to  indicate  a realization  that  new  operators  should  affect  the 
base  language. 


Requirement  F.4 

This  requirement  conflicts  directly  with  requirement  P7. 
Independently  of  that,  we  disagree  with  the  reauireirent  for  rea-jons 
explained  at  lenoth  in  the  comments  on  requirement  FI. 


Requirement  F7 

we  recommend  that  the  following  requirement  be  added:  "It  muct  be 
possible  to  compile  a p.roqram  so  that  there  is  no  overhead  caused  hy  run 
time  type  checkinq."  This  is  intended  as  a language  reouirement. 
Discriminated  union  implies  run  timp  type  checking,  supplied  bv  either 
the  compiler  or  the  procrammer  (as  in  ALGOL  6R).  For  a fully  debugged 
program,  the  overhead  of  this  must  he  avoidable.  if  the  language 
insists  on,  for  example,  a tao  field  for  a discriminated  union,  then  the 
compiler  cannot  remove  it  even  if  run  time  checking  is  not  wanted. 
There  are  many  wavs  in  which  a proaram  can  determine  the  type  in  a given 
instance;  a tag  field  should  not  be  mandatory. 


Feouirerrent  F? 

This  requirement,  toaether  with  requirement  F5,  implies  strongly 
that  the  Tinman  intends  a type  and  its  operations  to  be  defined  in  an 
isolated  "cluster",  with  the  objects  of  the  tyre  inaccessible  outside 
the  cluster  except  usino  the  defined  operations.  This  does  not  provide 
for  new  operations  which  have  arguments  of  more  than  one  type,  and  which 
must  have  access  to  the  representation  of  the  data  objects.  For 
example,  if  a new  set  type  is  defined  for  sets  built  at  run  tine,  an 
"add  member"  operation  might  need  to  access  both  a (normally 
inaccessible)  component  of  an  element  and  the  control  information  for 
the  set. 

Petter  than  a "cluster"  for  each  type  definition  is  a "cluster"  for 
a collection  of  type  definition.  the  Tinman  should  make  this  the 
requi rement . 


Requirement  F6 
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while  the  meaning  of  the  term  compool  is  less  restricted  than  it 
once  was,  it  has  remained  true  that  a compool  contains  only  things 
useful  at  compile  time.  Moreover,  a library  might  contain  a comoool, 
hut  why  must  a compool  be  able  to  contain  a library?  These  distinctions 
seem  useful.  We  don’t  see  the  advantage  of  merqinq  two  distinct 
concents  into  one. 


Requirement  6? 

The  Tinman’s  attitude  toward  the  goto  seems  ambivalent.  Tt  is  not 
eliminated  entirely,  and  there  is  no  restriction  against  using  it  to 
exit  from  an  entire  nest  of  loons  Tree  64).  (Our  reasoning  is  as 
follows:  Tinman  does  not  explicitly  require  any  control  structure  to  be 
a scope.  The  use  of  a goto  is  restricted  to  its  most  local  scope.  If 
control  structures  are  scopes,  then  the  goto  is  thereby  restricted  to 
the  point  of  uselessness  or,  worse,  to  being  used  poorly  only. 
Therefore,  Tinman  indeed  did  not  intend  for  control  structures  to  be 
scopes.)  Yet  there  is  a restriction  aaainst  using  a goto  out  of  an 
allocation  or  procedure  scope.  As  requirement  67  recognizes,  such  exits 
are  clearly  necessary;  special  mechanisms  are  therefore  required. 
Exception  handling  parameters  (requirement  C7)  are  required  as  one  such 
mechanism;  no  mechanism  is  identified,  cr  even  explicitly  mentioned,  for 
exit  from  allocation  scopes. 

Note  that  any  implicit  actions  (e.g.,  release  of  storage,  stack 
popping)  that  would  be  connected  with  a goto  out  of  an  allocation  or 
procedure  scope  are  necessary  in  any  case  for  the  special  exit 
mechanisms.  Less  complex,  but  similar,  mechanisms  are  needed  for  exit 
from  a nest  of  loops.  If  the  use  of  a qoto  is  thought  to  be  confusinq 
or  error  prone  in  the  first  case,  why  not  in  the  second  also?  That  is, 
if  special  exit  mechanisms  are  required,  why  not  spell  out  exactly  what 
is  wanted  where,  and  eliminate  the  goto  entirely? 

In  fact,  our  recommendation  would  be  to  keep  the  goto,  and  allow  it 
to  be  used  in  an  almost  unrestricted  manner  (a  prohibition  against  usinq 
a goto  to  enter  a control  structure  or  an  allocation  scope  is  certainly 
reasonable),  but  provide  enouoh  other  tools  so  that  its  use  was  rarely 
necessary. 


Reauirement  63 

The  use  of  the  complementary  clause  of  a control  structure  (else 
after  if  then  or  otherwise  after  case)  with  a null  statement  list 
occasionally  makes  a source  program  easier  to  read.  This  usually  occurs 
when  the  set  of  statements  followino  an  if  then  or  the  partitioning 
beinq  specified  by  a case  is  complicated,  for  example.  In  such  cases 
the  complementary  clause  has  the  visual  effect  of  a closing  bracket  for 
the  control  structure  and  tends  to  corvince  the  reader  that  he  has  not 
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missed  anythinq.  It  seems  a bit  severe  for  the  language  to  require  the 
comn lement ary  clause,  however.  For  example 

IF  X < 0 THEN  X = X + 1; 

would  simply  become  cluttered  by  the  inclusion  of  an  else  clause.  Such 
questions  should  probably  te  left  to  individual  style.  iFven  in  tightly 
controlled  developments  proc ramrre rs  should  be  allowed  some  freedor.) 


Reruirement  04 

we  applaud  the  requirement  that  a terminating  predicated  be  allowed 
to  appear  anywhere  in  the  loop.  As  noted  above,  this  also  strengthens 
our  goto  argument. 


Pecui  re  men  t GT> 

we  concur  wholeheartedly  with  the  decision  to  make  recursive 
procedures  a requirement.  we  believe  that  the  costs  of  recursion  are 
justified  by  its  contribution  to  clarity  and  conceptual  simplicity  for  a 
user . 

however,  we  do  not  aaree  with  the  restriction  aaainst  nesting 
recursive  procedures.  we  do  agree  that  such  nesting  occurs  rarely  — 
which  means  the  display  has  only  one  entry  normally  anyway,  it  the 
compiler  knows  which  procedures  are  recursive.  The  restriction 
therefore  has  no  real  run  time  advantages,  and  we  would  orefer  a 
requirement  callinq  for  declaration  of  the  fact  that  a procedure  is 
recursive.  In  general,  a compiler  cannot  develop  precise  information 
for  itself  (e.o.,  the  tact  that  R calls  P and  P calls  P does  not 
necessarily  mean  that  either  is  recursive).  with  or  without  the 
restriction  aqainst  nestino,  the  declaration  is  required  to  avoid  extra 
cost . 

It  the  restriction  aoainst  nesting  of  recursive  procedures  is 
nonetheless  kept,  then  we  note  that  it  could  be  relaxed  somewhat.  It  is 
only  recursive  procedures  in  recursive  procedures  which  cause  a 
multi-entry  display,  other  uses  of  stack  storage  (e.g.,  loc)  may  cause 
additional  pointers,  but  the  implementation  choices  are  the  same  here 
with  or  without  recursion.  It  is  a bit  tricky  to  avoid  extra  costs  due 
to  recursion  when  catlino  (non-recursi ve ) formal  parameter  procedures, 
but  it  can  be  done. 

I 

Requirement  r.S 
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As  the  Tinman  correctly  remarks,  synchronization  of  parallel 
processes  can  be  done  through  exclusive  access  to  data,  required  by  G6. 
It  can  also  be  done  by  calling  operating  system  or  other  synchronizing 
routines.  Hence,  the  meaning  of  this  requirement  is  unclear  — must 
additional  synchronization  tools  be  provided,  or  are  the  two  mentioned 
enough?  we  would  opt  for  the  second  alternative;  additional  tools 
should  not  be  outlawed,  but  neither  are  they  necessary,  and  deciding  on 
a set  compatible  with  various  different  environments  is  very  hard.  Note 
that  the  lanquaqe  BLISS,  which  supports  asynchronous  nrocessina, 
provides  no  synchronizing  primitives,  presumably  for  these  reasons. 

The  meaning  of  assigning  priorities  is  also  not  clear.  Typically, 
relative  priorities  change  with  time,  to  preclude  endless  waits  for  low 
priority  processes,  or  to  make  it  oossible  to  meet  deadlines.  ve 
certainly  oppose  building  a comprehensive  scheduling  mechanism  into  the 
language,  because  different  operatinr  system  disciplines  would  render 
much  of  it  meaningless.  Note  that  scheduling  can  be  programmed  in  any 
way  desired,  by  delaying  processes  to  wait  for  access  to  shared  data. 
Aoain,  it  is  not  clear  why  the  additional  requirement  is  necessary,  and 
what  it  accomplishes.  In  a particular  environment,  or  for  particular 
uses  (e.q.,  simulation),  scheduling  and  specific  synchronization 
mechanisms  can  of  course  be  programmed,  tut  requiring  general  ones  seem 
untenable.  The  problems  are  illustrated  by  CS-4,  which  has  nine 
scheduling  procedures,  four  synchroni z ing  ones,  and  si*  parameters 
describing  priority1  It  is  not  clear  that  these  are  meaningful  in  all 
cases,  or  even  that  they  are  sufficient. 

Treatment  of  hardware  and  other  interrupts  is  a different  auestion. 
Here  it  would  be  possible  to  provide  tools  in  the  lanquaqe,  as  PL/I  has 
done,  for  example.  However,  these  add  quite  a bit  of  mechanism  to  the 
language.  It  should  be  possible  to  tell  what  statement  caused  the 
interrupt  (where  applicable).  It  must  he  possible  to  enable  and  disable 
interrupts,  to  specify  the  action  to  be  taken  on  interrupt  as  a special 
kind  of  procedure  or  process,  to  cause  control  to  continue  where 
interrupted  (and  exact  definition  of  this  is  extremely  hard)  or  to  exit 
form  the  interrupt  procedure  without  resuming.  Debugging  of  interiupt 
orocedures  presents  special  problems  (in  PL/1,  SIGNAL  and  CONDITION  can 
he  used,  but  this  in  not  quite  the  same  as  an  actual  interrupt). 
Moreover,  control  over  interrupts  has  many  of  the  undesirable  traits  of 
the  goto;  control  in  interruoted  in  a definitely  "non-structured"  way. 
Therefore,  we  question  the  requirement  — the  added  complexity  may  not 
be  worth  the  gain. 

In  summary,  we  agree  only  with  the  part  of  the  requirement  calling 
for  access  to  real  time  clocks,  and  for  delays  based  on  elapsed  time  or 
the  occurrence  of  a specified  time.  The  other  facilities  called  for 
should  certainly  not  be  outlawed,  but  neither  should  they  be  required  of 
the  language. 


Requirement  H4 


2-14 


TINMAN 

Requirement  HA 


12 


we  suggest  the  addition  ot  a requirement  that  every  literal  he 
se If-identi tying  as  to  type.  To  prevent  confusion,  and  make  parsinn 
easier,  context  should  not  be  necessary  to  determine  the  type  of  a 
literal.  The  requirement  does  not  oreclude  the  use  of  immediate 
qualifiers,  as  in  for  example: 

complex:  (1.3, 4. 7) 


Requirement  14 

Thp  requirement  of  conditional  compilation  is  a nood  one.  Put  we 
believe  strongly  that  statements  which  are  to  be  executed  at  compile 
time  should  be  clearly  identified  as  such.  Otherwise,  the  flew  analysis 
problems  for  the  translator  can  be  severe,  and  there  is  no  reason  to 
impose  this  extra  burden. 


Requirement  J? 

It  is  difficult  to  understand  this  requirement  as  a language 
requirement.  Any  opt i mi zat i on  will  change  the  effect  of  a prooram  in 
some  sense.  Any  so-called  optimization  which  changes  the  semantics  of  a 
program  is  actually  a bun  in  the  compiler.  If  this  requirement  needs  to 
be  stated,  it  should  be  moved  to  section  L or  M. 


Requirement  J3 

A useful  feature  would  be  to  require  the  encapsulating  statements 
to  contain  information  specifying  the  hardware  features  for  whirb  the 
» dependent  code  is  being  written.  Nhen  a nroaram  written  for  one  object 
machine  is  compiled  for  another,  the  compiler  would  be  able  to  flag 
( machine  dependent  sections  which  have  not  been  modified.  (Notice  that 
including  machine  dependent  text  within  compile-time  conditional 
segments  which  depend  on  some  compile-time  variable  set  by  the 
rroorammer  merely  helps  generate  an  error-free  source  listing.  It  does 
not  point  out  sections  of  the  program  which  must  be  modified.)  For 
assembly  language  segments  the  specifyinn  information  could  be  as  simple 
as  the  symbolic  name  of  the  object  machine.  The  identifiers  for  the 
symbolic  names  could  be  administered  by  the  tanguaae  controller,  to 
ensure  uniformity  of  implementations,  and  would  not  have  to  be  treated 
as  reserved  words. 


Requi remrnt  J 4 
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As  we  suggested  under  requirement  J3,  the  hardware  features  assumed 
should  be  specified  in  the  encapsulating  statements,  but  here  the 
specifications  could  often  be  more  general  than  simply  the  oDject 
machine.  For  example,  the  number  of  bits  per  word  is  a feature  which 
could  sran  a numher  of  machines. 
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SECTION  3 - COMPARATIVE  EVALUATIONS 

This  section  is  tabulated  into  eight  subsections,  each  containing  an  assigned 
language  which  Computer  Sciences  Corporation  evaluated  against  Department  of 
Defense  requirements.  The  languages  are: 

CMS-2  JOVIAL  J3B 

CORAL  66  JOVIAL  J73 

CS-4  PEARL 

EUCLID  SPL/1 


t 
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A COMPARISON  OF 
CMS-2 
to 

TINMAN 


Final  Version 


31  December  1976 


PREPARED  BY 

COMPUTER  SCIENCES  CORPORATION 


* 
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CMS-2 


1 nt  roquet  i on 

This  report  gives  a comr  orison  of  the  language  CMS-?  to  the  Tinman 
language  requirements  (Department  of  Defense  Requirements  lor  H i oh  goder 
Computer  Programming  Lanouaoes,  "tinman"  - 1 March  1°76,  Section  IV). 
For  the  purposes  of  this  comparison,  C^S-?  is  considered  to  he  defined 
hy ; 

Users  Reference  Manual  for  Compiler,  Monitor 
System -2  (CMS-2)  for  Use  with  the  AN/UYF-7  Computer 
*-5035,  Vo l . T and  2 
FCDSSA  - San  Diem,  Cal. 

15  Auoust  1V75 

CMS-2 Y Programmer’s  Reference  Manual  (Preliminary 
Version) 

M-5D49 

FCDSSA  - San  Dieoo,  Cal. 

1 October  197A 


Tinman  contains  7f*  lamuaqe  requirements.  This  report  compares 
C*"S-2  to  each  requirement  individually.  If  a requirement  is  totally 
satisfied,  the  accompanyinn  text  is  a summary  of  the  particular 
mechanism  used.  (Occasionally  no  text  is  needed  if  a requirement  is 
totally  satisfied.)  If  a requirement  is  not  totally  satisfied,  the  text 
consists  of  a summary  of  the  shortcoroinqs  and  such  items  as  the  scone  o* 
the  changes  necessary  to  fully  meet  the  requirement  and  the  impact  of 
these  changes  on  existing  implementations. 

Each  Tinman  requirement  benins  with  an  introductory  ParaGraph. 
These  paragraphs  are  reproduced  in  this  report.  In  many  cases  they  are 
followed  by  several  single-line  summaries  of  features  in  the  area  of  the 
requirement.  Usually  these  are  features  which  are  specifically  called 
for  in  the  requirement.  A feature  enclosed  in  parentheses,  however,  is 
one  which  the  reviewers  thought  possibly  desirable,  even  though  not 
called  for  in  the  requirement. 

Symbols  placed  beside  the  introductory  paragraph  and  the  individual 
features  indicate  the  degree  to  which  the  reauirerrent  or  feature  is 
satisfied  by  the  language.  The  symbols  and  their  meanings  are: 

T - Totally  satisfied 

P - Partially  satisfied 

F - Fails  (not  satisfied  at  all) 

U - Unclear  from  the  documentation 

P*  - Almost  totally  satisfied 
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P-  - Only  slightly  satisfied 

N/A  — Not  applicable  (used  only  for  individual 
features  when  the  requirement  is  rot  satisfied 
at  all) 

(The  symbols  p,  P+,  and  P-  will  often  he  used  with  requirements  which 
are  stated  in  one  of  the  forms  "There  will  be  no..."  or  "All...",  even 
thouoh  only  T or  F are  technically  applicable  in  these  cases.) 

The  report  concludes  with  two  summaries.  The  first  is  of  the 
features  of  CMS-?  which  are  extraneous  to  Tinman  and  the  desirability  of 
retaining  each  of  them.  The  second  is  of  the  language  as  a whole  and 
the  desirability  of  modifyino  it  to  brinq  in  into  line  with  the  Tinman 
reoui rements . 


CmS-2 

Reouircment  A1 


1 


At.  The  lanouace  will  be  typed.  The  type  (or  mode)  of  alt 
variables,  components  of  composite  data  structures, 
expressions,  operations,  and  parameters  wilt  he  determinable 
at  compile  time  and  unalterable  at  run  time.  The  lanmiaae 
will  recuire  that  the  type  of  each  variable  and  component  of 
composite  data  structures  he  explicitly  scecified  in  the 
source  programs.  ....P 


The  language  nermits  the  user  to  exnli fitly  specify  the  type  of 
each  variable  and  component  of  a composite  aata  structure.  The  entity 
and  its  tyoe  may  te  declared  with  a variable  or  field  (component  of  a 
record)  declaration  staterent.  If  the  tyr°  is  not  specified  in  the 
declaration  the  entity  is  assigned  the  tyn»  specified  by  a mode 
declaration,  or,  if  there  is  no  mode  declaration,  a oefaulf  type.  in 
addition,  an  optional  declaration  (OPTIONS  fODEVRPL)  allows  the  user  tc 
use  local  variables  without  teino  required  to  declare  them.  The  type 
assigned  to  them  is  the  type  specified  by  the  mode  declaration  or 
default.  In  addition  a table  may  h3ve  a mairr  index  which  dynamically 
controls  the  number  rf  actual  items  in  the  table.  Specification  of  a 
major  index  is  considered  a variable  with  sioned  inteoer  typing  of  1 f> 
Dits  lenqth. 

Since  the  mode  declaration  and  MODEVRBl  option  are  error  pron^ 
(even  though  tn^  compiler  "alarinnly"  flags  all  WOPEVRRL  data  units) 
these  options  are  seldom  used.  It  is  a matter  cf  policy  for  usfrs  to 
declare  all  data  units. 

Removal  of  the  moDEVFBL  ortion  so  that  all  entities  must  be 
declared  and  recuirina  a major  index  to  be  cre-definea  would  b»  simple 
modifications  to  the  existinc  implementation. 

Tyre  checking  is  perfcrmea  at  compile  time.  however,  the  full 
intent  of  TINIYAN  is  not  met.  All  numeric  data  units  are  consiaered  to 
be  the  same  tyoe  for  assignment  and  expression  evaluation  and  implicitly 
converted  if  necessary.  (See  comments  under  A?  and  P8.)  Data  units  may 
share  the  same  strraae  (OVFRLAY  feature)  creatino  a tree  union,  but 
discrimination  is  not  permitted.  (See  comments  under  A7.) 


A?.  The  language  will  provide  data  types  tor  integer,  real 
(floating  point  and  fixed  print),  Poolean  ana  character  and 
will  provide  arrays  (i.e.,  composite  data  structures  with 
indexable  components  cf  homnteneous  type)  and  records  (i.e., 
corrrosite  data  structures  with  labeled  components  cf 
heterogeneous  type)  as  tvne  generators.  ....T 


lntecer  

Floating  Point 


T 

T 


cms-2 

Requirement  A2 


2 


Fixed  Point  T 

Boolean  F 

Character  String  .....T 

Arrays  T 

Records  r..T 


All  of  the  above  are  built-in  types  in  CMS-2.  For  type  checking 
purooses  all  numeric  data  units  are  considered  to  be  one  type. 

C¥S-2  has  a data  type  called  a TABLE  which  consists  of  any  number 
of  items.  An  item  is  an  arrangement  of  atomic  data  units,  i.e.,  a 
record.  A TABLE  may  be  an  array  of  items  (records)  or  a single  item 
(record)  but  a record  may  not  contain  an  array  or  a record.  To  permit 
records  to  contain  arrays  or  other  records  would  require  a major  change 
to  the  language  and  its  implementation. 

In  addition  to  the  binary  valued  Boolean  (true,  false),  the 
lanauage  contains  a multi-valued  Boolean  or  bit-string.  Only  the  binary 
valued  boolean  may  be  declared.  But  any  data  unit  can  be  considered  to 
De  a bit-string  and  its  tits  may  be  accessed  by  the  BIT  modifier  or 
manipulated  by  the  Boolean  operators  AND,  OR,  COMP  (complement)  and  XOR. 

CMS-2  also  includes  an  enumeration  type,  the  status  variable. 


A3.  The  source  lanauaqe  will  require  global  (to  a scope) 
specification  of  the  precision  for  floatinq  point  arithmetic 
and  will  permit  precision  specification  for  individual 
variables.  This  specification  will  be  interpreted  as  the 
maximum  precision  required  Dy  the  program  logic  and  the 


minimum  precision  to  be  supported  by  the  object  code.  ....F 

Global  arithmetic  precision  specification  mandatory  F 

Individual  variable  precision  specification  permitted  ..F 


The  lanquage  does  not  permit  a precision  to  be  specified  for 
floatina  point  arithmetic  or  for  individual  floating  point  data  units. 

CMS-2  is  a language  that  compiles  for  a single  machine,  the 
AN/UYr-7.  Floating  point  data  units  correspond  to  the  AN/UYK-7 
doubleword  format  for  floatinq  point  numbers.  They  always  have  a 
precision  of  31  bits. 
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»4.  Fixed  point  numbers  will  be  treated  as  exact  Quantities 
which  have  a renqe  srd  a fractional  step  size  which  are 
determined  by  the  user  at  compile  time.  Scale  factor 


manaqement  will  be  done  by  the  compiler.  . . . .P* 

Treated  as  exact  quantities  T 

Kanoe  and  step  size  determinen  at  compile  time  ...P* 

Scaling  handled  automatically  T 


Fixed  point  numbers  are  treated  as  exact  Quantities.  The  minimum 
number  of  bits  needed  to  represent  the  number,  and  the  number  of 
fractional  bits  are  specified  by  the  us**r  in  the  oeclaration.  This 
determines  the  maximum  absolute  value  the  number  can  assume.  The 
minimum  absolute  value  cannot  be  specified.  Scale  factor  management  is 
handled  by  the  compiler  unless  overridden  by  the  scilinn  specifier 
appended  oy  the  user  Ho  arithmetic  expressions. 

The  lanauaqe  has  a DFnUG  option  whirh  permits  the  user  to  specify  a 
complete  range  tor  each  data  unit.  Instructions  are  ne^f rated  to 
orovide  dynamic  ranqe  checkins.  Si  nee  the  mechanism  is  available  to 
accept  a complete  range  specification  it  would  be  a relatively  simple 
modification  to  permit  a complete  ranoe  to  be  specified  in  the  data  unit 
declaration  statement.  However,  instruction  aeneration  for  cynamic 
range  checkin’)  should  remain  optional. 


AS.  Character  sets  will  be  treated  as  any  other  enumeration 


type.  ....P- 

New  sets  can  be  defined  as  enumeration  types  .F 

ASCII  and  EBCDIC  are  provided  P 

(Conversion  capability  between  sets  is  available)  ............... h /A 


The  implementation  of  the  lanouane  uses  the  64  character  ASCII 
subset.  No  other  character  sets  are  permitted.  The  compiler  assumes 
that  all  peripheral  devices  use  *he  same  character  set. 

To  allow  the  user  to  specify  the  proqram  literal  and  order  of 
characters  would  require  only  a translation  table  for  conversion  from 
the  internal  representation  and  collatin';  sequence  used  by  the  compiler 
to  the  character  set  and  crllatinn  sequence  specified  by  the  user. 
Translation  would  only  be  necessary  by  the  portion  of  the  compiler  that 
generates  character  constants,  and  for  input/output  with  peripheral 
devices  that  use  a character  set  different  from  that  defined  oy  the 
user  . 
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If  the  character  set  defined  by  the  user 
are  not  in  the  64  characters  ASCII  subset  the 
by  the  compiler  must  be  expanded. 


can  have  characters  that 
character  set  recognizable 


A6.  The  language  will  require  user  specification  of  the 
number  of  dimensions,  the  range  of  subscript  values  for  each 
dimension,  and  type  of  each  array  component.  The  number  of 
dimensions,  the  type  and  the  lover  subscript  bound  will  be 
determinable  at  compile  time.  The  upper  subscript  bound  will 


be  determinable  at  entry  to  the  array  allocation  scope.  ....P 

Number  of  dimensions  is  fixed  at  compile  time  T 

Tyne  is  fixed  at  compile  time  T 

Lower  subscript  bound  is  fixed  at  compile  time  T 

Upper  subscript  bound  is  fixed  at  scope  entry  .................. .P 

Subscripts  only  inteqers  or  from  an  enumeration  type  ............P 

Subscripts  will  be  from  a contiguous  range  .T 


The  user  must  specify  the  number  and  size  of  each  dimension . The 
subscript  values  can  only  be  integers  and  must  be  contiguous  values 
starting  at  zero.  The  maximum  size  of  an  array  is  fixed  at  compile 
time,  except  for  simple  tables  (one-dimensional  arrays)  whose  maximum 
size  can  be  fixed  at  load  time.  In  addition,  the  size  of  simple  tables 
can  be  dynamic  by  declaring  a major  index,  a variable  that  controls  the 
upper  bound  on  the  table  subscript.  Declaration  of  a major  index 
automatically  defines  the  major  index.  Its  type  is  a signed  integer  of 
16  bits,  and  its  scope  is  the  same  as  the  scope  of  the  table. 

Subscript  values  can  be  values  of  an  enumeration  type  data  unit 
only  if  the  enumeration  type  data  unit  is  explicitly  converted  to  an 
integer  by  use  of  the  BIT  operator. 

A lower  hound  on  the  subscript  range  other  than  zero  or  one  would 
require  a change  to  the  array  declaration  syntax  and  a corresponding 
change  in  the  symbol  table. 

Fxtension  of  the  major  index  feature  to  all  arrays  would  be  a 
modest  change  to  the  compiler. 


A 7 . The  language  will  permit  records  to  have  alternative 
structures,  each  of  which  is  fixed  at  compile  time.  The  name 
and  tyre  of  each  record  component  will  be  specified  by  the 
user  at  compile  time. 


P 
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Alternative  structures  for  records  are  possible  .................  I 

Discrimination  condition  may  Le  any  Boolean  expression  ..........F 


Records  (ite»s  of  a table)  may  have  alternative  structures  either 
by  user  packing  of  the  fields  so  that  they  share  the  same  storage/  or  by 
use  of  the  field  overlay  feature  for  compiler  packed  fields.  The 
structures  are  fixed  at  compile  time  but  cannot  be  discriminated  at  run 
time. 


The  scope  of  modifications  necessary  to  implement  run  time 
discrimination  tor  alternative  structures  is  dependent  on  th-  syntax  and 
semantics  to  be  used. 
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31  . Assignment  end  reference  operation  will  be  automatically 
definea  for  all  data  types  which  do  not  manage  their  data 
storage.  The  assianment  operation  will  permit  any  value  of  a 
given  type  to  be  assigned  to  a variable,  array,  or  record 
component  of  that  type  or  of  a union  type  containing  that 
type.  Reference  will  retrieve  the  last  assigned  value. 


..T 


Automatically  defined  for  any  type  (except...)  .........T 

Available  for  individual  components  T 

(Assignment  and  reference  via  functions)  ........................  f 


Assignment  and  reference  is  defined  for  all  data  types  including 
arrays  and  records  and  for  their  components.  In  addition,  word 
components  of  arrays  and  records  can  also  be  assigned  and  referenced. 


B? . The  source  lanouage  will  have  a built-in  operation  which 
can  be  used  to  compare  any  two  data  objects  (regardless  of 
type)  tor  identity.  ....Pe 


Any  two  atomic  data  units  of  the  same  type  (all  numeric  data  units 
are  considered  to  be  the  same  "type")  may  be  compared  for  equivalence 
using  the  identity  predicates  Ed  (equals)  or  *'0T  (not  equals).  Arrays 
may  not  be  compared.  Components  of  arrays  (fields)  may  be  compared  if 
they  are  of  the  same  type. 

The  modification  of  the  existino  implementation  to  permit 
comparison  of  conformable  arrays  would  be  minor. 


83.  Relational  operations  will  be  automatically  defined  for 
numeric  data  and  all  types  defined  by  enumeration.  ,...P+ 

Puilt-in  for  all  numeric  and  enumeration  types  ....T 

Ordering  can  be  inhibited  when  desired  F 


All  six  relational  operations  (EG,  NOT,  GT,  GTEQ,  LT,  LTEQ)  are 
built-in  for  all  numeric  and  enumeration  types.  It  is  not  possible  to 
inhibit  the  ordering  of  the  values  for  an  enumeration  type. 

An  extra  piece  of  syntax  would  be  required  to  indicate  an  unordered 
enumeration  type.  The  modification  necessary  would  be  trivial. 
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P4.  The  built-in  arithmetic  operations  will  include: 
addition,  subtraction,  mu  1 1 ip  l i cat  i on,  division  (with  a real 
result),  exponentiation,  integer  division  (with  inteaer  or 
■fixed  point  arguments  and  remainder),  and  neaation.  ....T 

Addition  .......T 

Subtraction  T 

Multiplication  T 

Division  with  real  result  ..........T 

Exponentiation  T 

Integer  and  fixed  point  division  with  remainder  ...........T 

Negation  T 


Arithmetic  operations  use  familiar  notation:  addition,  ♦; 
subtraction,  -;  multiplication,  *;  division,  /;  exponentiation,  **. 
Negation  uses  the  unary  operator  -.  A division  with  real  (floating 
point)  result  occurs  if  either  of  the  operands  is  real.  The  remainder 
of  any  fixed  point  division  may  be  obtained  by  using  the  remainder 
operator  (SAVING  <data  unit>). 


P5.  Arithmetic  and  assignment  operations  on  data  which  are 
within  the  range  specifications  of  the  program  will  never 
truncate  the  most  significant  digits  of  a numeric  quantity. 
Truncation  and  rounding  will  always  he  on  the  least 
significant  digits  and  will  never  be  implicit  for  integers 
and  fixed  point  numbers.  Implicit  rounding  beyond  the 
specified  precision  will  be  allowed  for  floating  point 


numbers.  ....P 

Never  from  the  left  for  data  within  range  ...................... .T 

Never  on  the  right  for  integer  and  fixed  point  ..f 

Implicit  floating  point  rounriino  beyond  precision  allowed  ..P 

(Run  time  checks  can  be  avoided)  T 


For  arithmetic  and  assionment  operations,  CMS-?  never  truncates  the 
most  significant  digits  if  the  data  are  within  range.  Implicit 
truncation  is  performed  on  the  right  and  a warning  message  is  issued. 
For  floating  point  data  units  the  user  can  specify  in  the  data 
declaration  whether  implicit  rounding  is  to  be  performed  or  no  rounding 
is  to  be  performed. 

Run-time  checks  for  truncation  could  be  added  at  modest  cost. 
However,  run-time  checks  are  costly  to  the  user. 


- 
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86.  The  built-in  Boolean  operations  will  include  "and", 
"or",  "not",  and  "xor".  The  operations  "and"  and  "or"  on 


scalars  will  be  evaluated  in  short  circuit  mode.  ....P* 

Short-circuit  and  .T 

Short-circuit  or  .T 

Not  T 

Xor  . . . P 


CKS-?  has  two  sets  of  Boolean  operations:  Boolean  connectors  (i.e., 
topical  connectors  on  Boolean  data  units  or  expressions  as  in  SfT 
<Boolean  data  unit>  TO  <Boolean  data  unit>  AND  <Poolean  data  unit>  *); 
and  Boolean  operations  on  bit  strings  (as  in  SET  <inteaer>  TO  <integer> 
AND  <inteaer>  S). 

For  Poolean  data  units  the  language  provides  AND,  OR  and  COMP 
(complement).  The  implementation  of  AND  and  OR  is  short  circuit. 

For  bit  strings  the  language  provides  AND,  OR,  COPP  and  XOR. 

Implementation  of  the  logical  operator  XOR  would  require  a moderate 
addition  to  the  logical  code  reneration  sequences. 


P7.  The  source  language  will  permit 
assionment  on  conformable  arrays 
transfers  between  records  or  arrays 
structure. 


scalar  operations  and 
and  will  permit  data 
of  identical  logical 


Scalar  operations  on  arrays  P- 

Assinnment  between  records  and  arrays  of  conformable  type  T 


The  only  scalar  operation  permitted  on  arrays  is  assignment.  For 
example,  SET  TABARY  TO  5 S where  TABARY  is  an  array.  Fach  word  of 
TABARY  is  assigned  the  value  5.  All  scalar  assignments  to  tables 
(arrays)  and  to  items  (records)  of  tables  are  word  assignments. 

Assignment  between  tables  and  between  items  of  tables  is  permitted 
without  regard  to  the  types  or  logical  arrangement  of  the  components  of 
the  tables  or  items.  The  tables  or  items  do  not  need  to  be  conformable 
nor  of  the  same  length.  Transfer  is  accomplished  cn  a word  basis,  th 
length  of  the  shorter  determines  the  number  of  words  transferred. 


* 
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To  require  type  checking  and  contormabi  lity  checking  on  array  and 
record  transfers  and  to  allow  loaical  assignment  between  non-conf ormable 
arrays  would  require  a moderate  modification  of  the  current  compiler. 


BP.  There  will  be  no  implicit  type  conversions  but  no 
conversion  operation  will  he  required  when  the  type  of  an 
actual  parameter  is  a constituent  of  a union  type  which  is 
the  formal  parameter.  The  languaqe  will  provide  explicit 
conversion  operations  among  integer,  fixed  point  and  floating 
point  data,  between  the  object  reoresentation  of  numbers  and 
their  representations  as  characters,  and  between  fixed  point 


scale  factors.  ....h 

No  implicit  conversions  ......F 

Explicit  between  inteaer,  fixed  point,  and  floating  point  f 

Explicit  between  fixed  point  scale  factors  T 

(Explicit  between  integer  and  Boolean)  P 

(Explicit  between  integer  and  enumerated  types)  P 

(Explicit  between  different  enumerated  types)  F 


In  Cf*S -?  all  numeric  data  units  are  considered  to  be  the  same  type. 
Durinn  expression  evaluation  and  assignment  implicit  conversions  are 
performed  on  inteaer,  fixed  point  and  floating  point  data  units. 
Explicit  conversions  between  integer,  fixed  point,  and  floating  point 
data  units  are  not  required  nor  permitted.  However,  scale  factors  can 
be  explicitly  specified  on  fixed  point  data  units  and  fixed  point  data 
unit  expressions. 

An  explicit  conversion  can  be  performed  on  a Boolean,  a character 
type  or  an  enumeration  type  to  an  intecer  by  the  use  of  the  BIT 
operator.  An  integer  (or  any  otter  numeric  type)  may  not  be  converted 
to  a Boolean  or  an  enumeration  tyne.  Any  numeric  data  unit  or  any  data 
unit  converted  to  a bit  string  by  the  PIT  operator,  may  be  converted  to 
a character  type  by  use  of  the  CHAR  operator  (if  the  number  of  bits  is  a 
multiple  of  eight). 

Replacement  of  the  implicit  conversions  on  numeric  data  units  hy 
explicit  conversions  would  require  a moderate  change  to  the  existinq 
compi ler . 


R9 . Explicit  conversion  operations  will  not  be  required 
between  numerical  ranges.  There  will  be  a run  time  exception 
condition  when  any  inteoer  or  fixed  point  value  is 
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in 


truncated.  ....P* 

Implicit  conversion  between  ranges  T 

Fxception  condition  on  integer  and  fixed  point  truncation  .......P 

Explicit  conversion  operations  are  not  required  between  two 
numerical  data  units  that  are  cut  cf  range.  It  truncation  occurs  the 
compiler  issues  a warning  message. 


A run-time  exception  condition  for  truncation  could  be  added  at 
modest  cost. 


BID.  The  base  lanouage  will  provide  operations  allowing 
programs  to  interact  with  files,  channels,  or  devices, 
includino  terminals.  These  operations  will  permit  sendino 
and  receivino  both  data  and  control  information,  will  enable 
programs  to  dynamically  assion  and  reassign  I/O  devices,  will 
provide  user  control  for  exception  conditions,  and  will  not 


be  installation  dependent.  ....P* 

Sending  and  receiving  of  data  T 

Sending  and  receiving  of  control  information  .....T 

Dynamic  device  assionment  F 

user  exception  condition  control  .p 

Installation  independence  T 

(Data  formatting  capability)  T 

(Reading  and  writing  of  bit  strings)  .T 

CMS-?  has  a rudimentary  high  level  I/O  capability.  With  it  the 


user  can  transfer  data  between  his  program  and  named  files  on  tape  or 
disk,  and  standard  I/O  devices  (card  reader,  printer,  punch,  and 
operator's  console),  in  a formatted  or  unformatted  form.  The  1/0 
operations  require  the  use  of  library  run-time  routines  and  the  CMS-? 
monitor. 

The  CMS-2  hiah  level  I/O  capability  provides  the  equivalent  of  what 
one  would  need  in  a typical  batch  environment,  and  is  not  sufficient  tor 
tactical  data  systems.  The  I/O  functions  in  embedded  executives  in  most 
tactical  data  system  applications  are  usually  written  in  direct 
(embedded  assembly  lanquaae)  code. 

Expansion  of  the  hiqh  level  1/0  capability  to  provide  the  functions 
necessary  tor  tactical  data  system  applications  would  be  a major  effort. 
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P11.  The  lanouaae  will  provide  operations  on  data  types 
defined  as  power  sets  of  enumeration  types  (see  FA).  These 
operations  will  include  union,  intersection,  difference. 


complement,  and  an  element  predicate.  ....F 

union  .......F 

Intersection  F 

Difference  ..F 

Complement  f 

Membership  predicate  F 

(Set  inclusion)  F 


Although  an  enumeration  type  (status  variable)  is  a permissible 
type  the  powerset  of  an  enumeration  type  cannot  he  oefined,  nor  can  any 
of  the  set  operations. 

The  inclusion  of  powersets  and  their  operations  would  have  no 
impact  on  existin’)  features  in  the  lanquage  ane*  could  be  added  at  modest 
ccst . 
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Cl.  Side  effects  which  are  dependent  on  the  evaluation  order 
amono  the  arguments  of  an  expression  will  he  evaluated 


lett-to-r ioht . ....T 

Side  effects  must  occur  in  lef t-to-right  order  .................. T 

(Embedded  assignments)  ....... ....F 


Those  arouments  of  an  expression  that  can  cause  side  effects  are 
evaluated  lett-to-r ioht . 


C2.  which  parts  of  an  expression  constitute  the  operands  to 
each  operation  within  that  expression  should  be  obvious  to 
the  reader.  There  will  be  few  levels  of  operator  hierarchy 


and  they  will  be  widely  recognized. 

Few  precedence  levels  T 

No  user-defined  precedence  levels  T 

Operands  of  an  operation  are  obvious  P* 


CMS-2  has  six  precedence  levels,  within  the  same  precedence  level 
evaluation  is  from  lef t-to-r ioht  unless  the  operation  to  be  performed 
first  is  specified  by  parentheses  or  a unary  minus  is  encountered  before 
or  after  an  exponentiation  operation,  in  which  case  the  operations  are 
performed  from  right-to-left.  The  lef t-to-right  evaluation  defines 
X/Y/Z  as  equivalent  to  (X/Y )/Z.  The  only  exception  to  these  rules  is 
the  expression  evaluation  for  substitution  declarations.  See  the 
comments  on  requirement  H10. 


C3.  Fxpressions  of  a oiven  type  will  be  permitted  anywhere 
in  source  programs  where  both  constants  and  references  to 
variables  of  that  type  are  allowed.  ...,P* 


CMS-2  permits  expressions  anywhere  both  constants  and  variables  are 
allowed.  The  form  of  an  expression  for  substitution  declarations  is 
different  from  expressions  in  other  contexts.  See  the  comments  on 
requirement  H10. 
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C 4 . Constant  expressions  hill  be  allowed  in  proorams 
anywhere  constants  are  allowed,  and  constant  expressions  will 
be  evaluated  before  run  time.  ....T 


This  requirement  is  fully  met. 


C5.  There  will  be  a consistent  set  of  rules  aoplicable  to 
ell  parameters,  whether  they  be  for  procedures,  for  types, 
for  exception  handling,  for  parallel  processes,  for 
declarations,  or  for  built-in  operators.  There  will  te  no 
special  operations  (e.o.,  array  substructur ina ) applicable 
only  to  parameters.  Uniformity  and  consistency  contribute  to 
ease  of  learnino.  ....T 

Parameter  rules  consistent  in  all  contexts  T 

No  special  operations  applicable  only  to  parameters  T 


There  is  a consistent  set  of  rules  for  each  class  of  parameters. 


C6 . Formal  and  actual  parameters  will  always  agree  in  type. 
The  number  of  dimensions  for  array  parameters  will  be 
determinable  at  compile  time.  The  size  and  subscript  range 
for  array  parameters  need  not  be  determinable  at  compile 


time,  but  can  be  passed  as  part  of  the  parameter.  ....P 

Actual  and  formal  parameters  will  agree  in  type  ................ + 

Rank  of  parameter  arrays  is  fixed  at  compile  time  ....T 

Parameter  array  size  and  subscriot  range  can  be  passed  ..........P 


The  type  rules  for  actua l /formal  parameters  are  the  same  as  for 
assionment:  Actual  and  formal  parameters  must  agree  in  type  except  that 
all  numeric  data  units  are  considered  to  be  the  same  type. 

The  size  and  subscript  ranoe  of  parameter  arrays  cannot  be 
explicitly  passed.  However,  a formal  or  actual  procedure  input  (or 
output)  parameter  can  be  a table  with  a major  index.  The  major  index  on 
a simple  table,  i.e.,  a one  dimensional  array,  can  be  passed  explicitly 
as  a parameter. 

See  the  comments  on  A/'. 
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C 7.  There  will  he  only  Tour  classes  oi  formal  parameters, 
for  data  there  will  be  those  which  act  as  constants 
representing  the  actual  parameter  value  at  the  time  oi  call, 
and  those  which  rename  the  actual  parameter  which  must  be  a 
variable.  Tn  addition,  there  will  be  a formal  parameter 
class  for  specifying  the  control  action  when  exception 
conditions  occur  and  a class  for  procedure  parameters. 


Act  as  constants  (call  by  value  plus)  ....F 

Act  as  variables  (call  by  reference)  P- 

Fxception  control  T 

Procedure  parameters  f 

(Act  as  variables,  but  call  by  value)  T 

(Act  as  variables,  result  parameter)  T 


A procedure  in  CMS-?  may  have  input  parameters,  output  parameters 
and  abnormal  exit  parameters.  Abnormal  exit  parameters  are  label  names 
on  the  calling  side  ana  condition  names  on  the  called  side.  The  label 
names  need  not  be  within  the  scope  of  the  calling  procedure  but  must  be 
within  the  scope  of  the  system-procedure  containinq  the  callinq 
procedure . 

Input  and  output  parameters  are  called  by  value  (except  for  input 
of  indirect  tables).  Assignment  to  the  formal  parameter  is  permitted 
within  called  procedure.  Assignment  to  formal  input  parameters  does  not 
affect  the  actual  input  parameters. 

Indirect  tables  are  the  one  exception  to  call  by  value.  The 
address  of  any  simple  table  (by  use  of  the  fORAD  functional  modifier) 
may  be  passed  as  an  actual  oarameter  to  an  indirect  table  formal  input 
parameter,  and  hence  is  a call  bv  value.  Assiqnment  to  the  formal 
parameter  effects  the  actual  parameter. 

A redefinition  of  formal  parameters  would  result  in  a major  impact 
on  the  existing  implementation. 


CP.  Specification  of  the  type,  ranqe,  precision,  dimension, 
scale,  and  format  of  parameters  will  be  optional  in  the 
procedure  declaration.  None  of  them  will  be  alterable  at  run 


time.  .«..f 

Above  properties  optional  f 

Above  properties  are  fixed  at  run  time  .......................... F 
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CPS-2  does  not  permit  the  writinq  of  qeneric  procedures . 

Implementation  of  this  requirement  would  require  major 
modifications  to  the  existing  parameter  mechanism. 


C9.  There  will  be  provision  for  variable  numbers  of 
arguments,  but  in  such  cases  all  tut  a constant  number  of 
their,  must  be  of  the  same  type.  Whether  a routine  can  have  a 
variable  number  of  arguments  must  he  determinable  from  its 
description  and  the  number  of  arouments  for  any  call  will  hr 


determinable  at  compile  time.  ....F 

Variable  number  of  arguments  possible  F 


£ll  tut  a constant  number  of  arguments  have  the  same  tyre  .......F 

Number  of  arouments  in  each  call  is  fixed  at  compile  time  .......F 


Cms-?  does  not  permit  a variahle  number  of  arouments. 

Implementation  of  this  requirement  would  require  major 
modifications  to  the  existing  parameter  mechanism. 
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Reauirement  D1 

01.  The  user  will  have  the  ability  to  associate  constant 
values  of  any  type  with  identifiers.  ....T 

Py  use  of  the  EQUALS  and  MEANS  substitution  features  an  identifier 
can  be  associated  with  any  constant. 


D?.  The  lanquage  will  provide  a syntax  and  a consistent 
interpretation  for  constants  of  built-in  data  types.  Numeric 
constants  will  have  the  same  value  (within  the  srecified 
precision)  in  both  programs  and  data  (input  or  output).  ....P 

Literals  for  all  built-in  types  T 

Consistent  interpretation  in  program  and  data  u 

Literals  are  provided  tor  all  atomic  data  types.  The  documentation 
is  not  clear  as  to  the  consistency  of  numeric  constants  in  both  programs 
and  input  or  output  data. 


D3 . The  language  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  part  of  their  declaration. 

Such  variables  will  be  initialized  at  the  time  of  their 
apparent  allocation  (i.e.,  at  entry  to  allocation  scope). 

There  will  be  no  default  iritial  values.  ....T 

Initial  value  can  be  specified  as  part  of  the  declaration  T 

Initialization  occurs  at  allocation  scope  entry  T 

No  default  initial  values  T 

The  initial  value  for  any  numeric,  character.  Boolean  or 
enumeration  variable  or  field  (component  of  a record)  can  be  specified 
as  part  of  its  declaration  or  can  be  specified  separately  with  a data 
declaration  statement.  If  not  specified  there  is  no  default  value.  All 
data  units  are  allocated  at  the  time  of  their  declaration. 
Initialization  of  arrays  and  records  must  be  accomplished  by  declarinq 
initial  values  for  their  components. 


D4 


The  source  language  will  require  its  users  to  specify  . 


r 


Requirement  DA 


individually  the  range  of  all  numeric  variables  and  the  step 
size  for  fixed  point  variables.  The  ranoe  specifications 
will  be  interpreted  as  the  maximal  range  of  values  which  will 
be  assigned  to  a variable  and  the  minimal  range  which  must  be 
supported  by  the  obiect  code.  Ranae  and  step  size 
specifications  will  not  be  interpreted  as  defining  new 


tynes.  ....P 

Numeric  variable  range  specification  mandatory  ......... .........P 

Fixed  point  variable  step  size  specification  mandatory  .T 


Range  and  step  size  specifications  do  not  define  a new  type  T 


For  fixed  coint  numeric  variables  and  fields  (components  of  a 
record)  the  maximum  absolute  value  and  the  step  size  must  be  specified 
by  declaring  the  maximum  number  of  bits  required  to  represent  the 
numeric  and  the  position  of  the  binary  point.  The  minimum  absolute 
value  cannot  be  specified  and  is  assumed  to  be  zero.  The  range  for 
floating  point  numerics  cannot  be  specified. 

The  language  has  a DEBUG  option  which  permits  the  user  to  specify  a 
complete  range  for  each  data  unit.  See  the  comments  for  requirement  AA. 


f>5.  The  ranqe  of  values  which  can  be  associated  with  a 
variable,  array,  or  record  component,  will  be  any  built-in 
type,  any  defined  type,  or  a contiguous  subsequence  of  any 


enumeration  type.  ....P 

Ranges  of  an  enumeration  type  are  allowed F 

No  arbitrary  restrictions  on  the  structure  of  data  .............. P 


The  values  which  can  be  associated  with  a variable  or  a record 
component  (field)  can  be  any  atomic  data  type.  » component  ot  a record 
cannot  be  an  array  or  another  record.  A component  of  an  array  can  only 
be  a record  or  an  atomic  data  type.  (See  the  comments  on  reouirement 
A2  . ) 


06.  The  lanauage  will  provide  a pointer  mechanism  which  can 
be  used  to  build  data  with  shared  and/or  recursive 
substructure.  The  pointer  property  will  only  affect  the  use 
of  variables  (including  array  and  record  components)  of  some 
data  types.  Pointer  variables  will  be  as  safe  in  their  use 
as  are  any  other  variables.  ....P- 
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Recursive  and  network  structures  provided  r 

Handles  variable-value  and  structure-component  connections  F 

Pointer  property  is  an  attribute  of  a typed  variable  r 

Pointer  property  not  for  constants,  affects  only  assignment  F 

Pointer  property  mandatory  for  dynamic  allocation  F 

Allocation  scope  never  wider  than  access  scope F 

(Either  the  value  or  the  pointer  is  modifiable)  F 

(Pointer  mechanism  handles  procedures  and  parameters)  ...........F 

(Remap  and  replace  assignment  have  different  syntaxes)  F 

(Built-in  dynamic  variable  creation)  .. F 

(Variable  equivalence  classes  are  declarable)  F 


There  is  a very  limited  pointer  mechanism  available  by  use  of  the 
intrinsic  CORAD  function.  The  address  of  any  data  unit  can  be 
referenced  and  assigned  to  any  numeric  variable  or  field  (component  of  a 
record).  However  there  is  no  mechanism  for  indicating  that  the  value  of 
a variable  is  an  address.  The  CORAD  function  is  used  primarily  for 
indirect  tables. 

The  full  impact  of  the  implementation  of  a pointer  mechanism  cannot 
be  ascertained  without  a full  description  of  the  syntax  and  semantics. 
However,  any  implementation  of  a pointer  mechanism  would  be  a major 
modification  to  the  compiler. 
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El.  The  user  of  the  lanauage  will  be  able  to  define  new  data 
types  and  operations  within  rroorams.  ....P 


New  operations  are  definable  only  hy  the  use  of  functions.  Since 
almost  all  languages  have  functions  it  is  assumed  that  the  use  of 
functions  as  new  operations  definitions  is  not  the  intent  of  TINMAN. 

New  types  are  definable  by  only  enumeration  (status  variables)  or 
by  records  (items  of  a table).  See  the  comments  on  requirement  a?. 

Addinq  the  capability  to  define  new  operations  to  the  language 
beyond  the  use  of  functions  would  recuire  major  modifications  to  the 
language  and  its  implementation. 


E?.  The  "use"  of  defined  types  will  be  indistinguishable 
from  built-in  types.  ....F 


The  only  definable  types,  enumeration  and  records,  are  also 
built-in.  Although,  as  stated,  the  requirement  could  be  considered  to 
be  literally  met,  the  intent  of  Tinman  is  not. 


E 3 . Each  program  component  will  be  defined  in  the  base 
language,  in  a library,  or  in  the  program.  There  will  be  no 
default  declarations.  ....p 


Local  variables  need  not  be  declared  if  OPTIONS  MODE VRBL  has  been 
declared,  and  the  type  of  a variable  (or  component  of  a record)  may  be 
omitted.  See  the  comments  on  requirement  A1. 

System  and  local  indexes,  when  declared,  are  defaulted  to  signed 
integer  types  with  a lenoth  of  16  bits.  Removing  system  or  local 
indexes  would  be  a trivial  modification.  Allowing  system  and  local 
indexes  to  be  declared  any  type  would  be  a modest  change  to  the  language 
and  its  implementation. 


I 


E4 . The  user  will  he  able,  within  the  source  languaqe,  to 
extend  existing  operators  to  new  data  types. 


P- 
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The  only  defined  types  permissible  are  the  enumeration  type  and  the 
record.  Assignment  can  be  extended  to  both  of  these  types.  In 
addition,  all  of  the  comparison  operations  can  be  applied  to  enumeration 
types . 


E5.  Type  definitions  in  the  source  language  will  permit 
definition  of  both  the  class  of  data  objects  comprising  the 


type  and  the  set  of  operations  applicable  to  that  class.  * 
defined  type  will  not  automatically  inherit  the  operations  of 
the  data  with  which  it  is  represented.  ....F 

Construction  .......F 

Selection  ..................F 

Predicates  F 

Type  conversions  F 

Operations  and  data  can  be  defired  together  .F 


There  are  no  definable  operations  in  CMS-?. 


F6 . The  data  objects  comprising  a defined  type  will  be 
definable  by  enumeration  of  their  literal  names,  as  Cartesian 
products  of  existing  types  (i.e.,  as  array  and  record 
classes),  by  discriminated  union  (i.e.,  as  the  union  of 
disjoint  types)  and  as  the  power  set  of  an  enumeration  type. 
These  definitions  will  he  processed  entirely  at  compile 


time.  . . . . P 

Enumeration  7 

Cartesian  products  (records)  T 

Discriminated  union  F 

Powerset  of  an  enumeration  type F 


The  only  ways  to  define  new  types  is  by  enumeration  (status 
variables)  and  by  records  (items  of  a table).  Implementation  of 
discriminated  union  and  powerset  of  an  enumeration  type  would  require  a 
major  modification  to  the  language  and  the  compiler. 


definitions  by  free  union 


(i.e.,  union 


of 
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non-disjoint  types)  and  subsetting  are  not  desired.  ....p- 

Free  union  is  permitted  using  the  overlay  -features.  Subsettinj  is 
only  permissible  on  arrays  (sub-tables). 

The  overlay  capability  can  he  easily  removed. 


FP.  When  definino  a type,  the  user  will  be  able  to  specify 
the  initialization  ard  finalization  ororedures  for  the  type 
and  the  actions  to  be  taken  at  the  time  of  allocation  r-nd 


deallocation  of  variables  of  that  type.  ....F 

Initialization  F 

Finalization  ...F 

Allocation  actions  F 

Deallocation  actions  .........F 


CPS-?  does  not  provide  any  encapsulated  means  of  defining 
initialization,  finalization,  allocation  or  deallocation  actions  for 
defined  types. 

Any  other  means  of  defininq  actions  would  renuire  a major 
modification  to  the  language  and  the  compiler. 
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FI.  The  language  will  allow  the  user  to  distinguish  between 
scope  of  allocation  and  scope  of  access. 


The  scope  of  allocation,  or  lifetime,  of  all  data  structures 
(except  local  indexes)  is  the  entire  life  of  the  program.  The  scooe  of 
access  for  data  structures  defined  in  system-data-designs  is  the  entire 
program,  i.e.,  the  data  structures  are  common  to  all  procedures.  The 
scope  of  access  for  data  structures  defined  within  loca l-data-des igns  is 
the  system-procedure  which  contains  the  local-data-desipn,  i.e.,  the 
data  structures  are  common  to  all  procedures  within  the 
system-procedure. 

A local  index  is  defined  at  the  beginning  of  a procedure  and  exists 
throughout  the  procedure.  Its  scope  of  allocation  and  scope  of  access 
are  identical. 

what  is  missing  in  CWS-2  is  the  capability  of  limiting  the  scope  of 
access  for  any  data  structure  to  a procedure  or  to  any  lower  level.  The 
changes  to  the  compiler  necessary  to  incorporate  this  capability  would 
be  a moderate  modification  to  the  symbol  table  and  the  symbol  table 
accessing  mechanisms. 


F2.  The  ability  to  limit  the  access  to  separately  defined 
structures  will  be  available  both  where  the  structure  is 
defined  and  where  it  is  used.  It  will  be  possible  to 
associate  new  local  names  with  separately  defined  program 


components.  ....P- 

Allowable  operations  can  be  limited  F 

Access  can  be  limited  where  used  ..P- 

External  declarations  need  not  all  have  the  same  scope  F 

Naming  conflicts  can  be  avoided  (renaming)  F 


Access  to  data  structures  or  program  structures  is  limited  by  the 
location  of  the  data  or  program  structure  definition.  Data  structures 
are  either  global  to  the  entire  program,  local  to  the  system  procedure 
or  local  to  a procedure  (local  indexes).  See  comments  under  requirement 
FI.  Access  rules  cannot  be  specified  either  where  the  structure  is 
defined  or  where  it  is  used,  except  that  it  is  possible  to  define  a 
structure  (either  procedure  or  data)  as  being  global  to  the  entire 
program,  by  use  of  the  EXTDEF  modifier,  even  though  its  location  would 
make  it  local  to  the  system-procedure . 

The  modifications  necessary  to  define  access  where  the  structure  is 
called  cannot  be  assessed  at  this  time. 


¥ 
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F 3 . The  scope  of  identifiers  Kill  be  wholly  determined  at 
compile  time.  ....P* 


The  scope  of  identifiers  is  wholly  determined  at  compile  time.  An 
identifier  that  is  qlobal  cannot  be  duplicated  at  a local  level. 
However,  an  identifier  that  is  local  to  one  system-procedure  and  an 
identifier  that  is  local  to  another  system-procedure  can  have  the  same 
name . 


Lexically  embedded  access  scopes  would  only  be  meaningful  if  the 
language  provided  tor  data  definitions  at  a level  lower  than  system 
procedures.  At  present  the  only  data  definitions  permissible  within  a 
procedure  is  a local-index.  See  the  comments  under  FI. 


F4 . A variety  of  apnlication-oriented  data  and  operations 
will  be  available  in  libraries  and  easily  accessible  in  the 
language.  . . . „ T 


Applications  oriented  data,  procedures,  and  functions  can  be  stored 
in  common  libraries  that  are  easily  accessible  in  the  language. 


F5 . Program  components  not  defined  within  the  current 
proaram  and  not  in  the  base  lanquage  will  be  maintained  in 
compile  time  accessible  libraries.  The  libraries  will  be 
capable  of  holdinq  anything  definable  in  the  lanauage  and 
will  net  exclude  routines  whose  bodies  are  written  in  other 


source  languages.  ....P 

Prooran  component  libraries  accessible  at  compile  time  T 

Libraries  can  contain  foreion  lanquaqe  routines  .u 

Interface  requirements  checkable  at  compile  time  F 


Proqram  components  and  data  in  either  source  or  object  form  or 
compools  can  be  selected  from  compile  time  accessible  libraries. 
Provided  that  the  object  output  from  foreign  lanquaqe  compilers  is 
compatible  with  the  CMS-2  UYr-7  loader  there  does  not  appear  to  be  any 
reason  why  a library  cannot  contain  a program  component  that  had  been 
originally  written  in  a foreign  language. 
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F6.  Libraries  and  Compools  will  be  indistinguishable.  They 
will  be  capable  of  holdino  anything  definable  in  the 
language,  and  it  will  be  possible  to  associate  them  with  any 
level  of  programming  activity  from  systems  through  projects 
to  individual  proarams.  There  will  be  many  specialized 
compools  or  libraries  any  user  specified  subset  of  which  is 


immediately  accessible  from  a given  program.  ....p* 

Libraries  and  compools  will  be  indistinguishable  P* 

Immediately  accessiole  sublibraries  at  any  level  T 

CKS-2  libraries  are  collections  of  program  elements 


(system-procedures  and  system-data-designs) . System-procedures  may  be 
in  object  or  source  format.  System-data-designs  may  be  in  object, 
source,  or  partially  compiled  (compool)  format.  The  language  permits 
the  selection  of  any  program  element  that  is  in  source  or  compool 
format.  (The  librarian  and  loader  may  select  any  element  in  object 
format.)  However,  if  the  element  is  in  compool  format  the  user  must 
specify  that  it  is  a compool  that  is  being  selected. 

Changing  the  compiler  so  that  the  user  would  not  have  to  specify 
the  kind  of  program  element  would  be  a minor  modification.  From  the 
user*s  point  of  view  the  compool  would  be  indistinguishable  from  any 
other  program  element. 


F7.  The  source  language  will  contain  standard  machine 
independent  interfaces  to  machine  dependent  capabilities, 
including  peripheral  equipment  and  special  hardware.  ....P- 


CFiS-2  provides  a limited  hiah  level  1/0  capability  and  interface 
with  hardware.  See  the  comments  on  requirement  BIO. 
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G1 . The  language  will  provide  structured  control  mechanisms 
for  sequential,  conditional,  iterative,  and  recursive 
control.  It  will  also  provide  control  structures  for 

(pseudo)  parallel  processing,  exception  handlinq,  end 

asynchronous  interrupt  handling.  ...,u 


Sequential  execution  T 

Conditional  execution  T 

Iter  at  ion  ...T 

Recursion  f 

(Pseudo)  parallel  processing  

Exception  hand  l i no  ..F 

Asynchronous  interrupt  handling  F 


Control  structures  from  a small  set  of  simple  primitives 


Sequential  execution:  Unless  a statement  involves  a branch  the  next 
statement  to  be  executed  is  the  statement  immediately  followina.  In 
addition,  statements  ray  be  connected  with  a THEN,  as  in:  IF  <conoition> 
THEN  <statement>  THEN  <statement>  ...  ELSE...  or  <statement>  THEN 
<statement>  ...  j. 

Conditional  execution  is  provided  for  by  the  IF  <condition>  THEN 
...  ELSE  structure,  the  case  structure  (FOR  <expression>) , and 
switches. 

Iteration  is  provided  for  by  the  VARY  block  structure. 

Exception  handlina:  abnormal  exit  parameters  and  overflow 
condition. 

No  syntax  extension  capabilities  exist  in  CWS-2  to  build  new 
control  structures.  Wore  powerful,  and/or  special  purpose  control 
structures  have  been  provided,  traditionally,  by  the  addition  of  new 
primitives  to  the  lanquane,  e.q.,  FIND  is  a table  searching  control 
structure  combining  iteration  and  a conditional.  A high  level  macro 
capability  could  be  implemented  for  a moderate  effort. 


G2.  The  source  language  will  provide  a "GO  TO"  operation 
applicable  to  program  labels  within  its  most  local  scope  of 
definition.  ...,R 


The  language  provides  a GOTO  operation.  However,  in  CNS-2Y  the 
GOTO  label  can  be  to  any  label  within  the  system-procedure.  Later 
versions  of  CNS-?  (such  as  CMS-?*)  restrict  the  GOTO  to  procedure  scope. 
In  addition,  *he  language  permits  switches. 
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Imposing  that  GOTO  labels  be  restricted  to  procedure  scope  (or  to 
any  other  scope  rules)  and  eliminating  switches  would  require  only  a 
minor  modification  to  the  language. 


G3.  The  conditional  control  structures  will  be  fully 
partitioned  and  will  permit  selection  among  alternative 
computations  based  on  the  value  of  a °oolean  expression,  on 
the  subtype  of  a value  from  a discriminated  union,  or  on  a 


computed  choice  among  labeled  alternatives.  ....Pt 

Based  on  Boolean  expression  T 

Based  on  type  from  discriminated  union  F 

Rased  on  computed  choice  amono  labeled  alternatives  T 

All  alternative  must  be  accounted  for  .....F 

Simple  mechanisms  will  be  supplied  for  common  cases  ............. P 


Conditional  control  is  provided  for  by  the  I F-THE N-E LSfc , the  case 
statement  (FOR)  and  switches.  The  IF-THEN-ELSE  is  a common  case  for 
selection  of  the  alternatives  based  on  the  value  of  a Poolean 
expression.  The  case  statement  and  switches  provide  for  a computed 
choice  amonq  labelled  alternatives,  for  all  of  the  conditional  control 
mechanisms  the  language  does  not  require  that  all  alternatives  be 
accounted  for  (e.g.,  an  ELSE  is  not  required  to  be  specified  after  the 
IF  THEN).  Discriminated  union  is  not  permitted  by  the  language. 

The  case  statement  was  added  to  the  language  to  provide  the  same 
capabilities  as  the  switch  mechanism  in  a more  structured  form  and  to 
localize  the  scope  to  the  structure.  The  switch  mechanism  can  be 
removed  with  relatively  little  impact. 


G4.  The  iterative  control  structure  will  permit  the 
termination  condition  to  appear  anywhere  in  the  loop,  will 
require  control  variables  to  be  local  to  the  iterative 
control,  will  allow  entry  only  at  the  head  of  the  loop,  and 
will  not  impose  excessive  overhead  in  clarity  or  run  the 
execution  costs  for  common  special  case  termination 
conditions  (e.g.,  fixed  number  of  iterations  or  elements  of 


an  array  exhausted).  ... .P* 

Termination  can  occur  anywhere  in  the  loop  .....P+ 

Multiple  terminating  predicates  are  possible  ................... .T 

Entry  permitted  only  at  the  loop  head  F 

Simple  cases  are  clear  and  efficient  T 
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Control  variable  is  local  to  the  loop  ...P- 

Control  value  is  efficiently  available  after  termination  P 


Iterative  control  is  provided  for  by  the  VARY  statement. 
Termination  can  be  aftter  a fixed  number  of  iterations,  at  the  beginning 
of  an  iteration  upon  failure  of  a test  (WHILE),  or  at  the  end  of  an 
iteration  upon  failure  of  a test  (UNTIL).  The  only  termination  of  the 
loop  permitted  within  the  loop  is  by  use  of  a GOTO  outside  the  loop. 
Termination  of  any  iteration  within  the  loop  and  commencement  of  the 
next  iteration  can  be  accomplished  by  a RESUME  statement.  In  addition, 
the  resume  statement  can  be  used  outside  of  the  loop  if  the  loop  was 
terminated  by  a GOTO  outside  the  loon. 

Entry  is  permitted  into  the  loop  at  any  labelled  statement. 

If  a data  unit  is  specified  as  the  loop  control  variable  the  oata 
unit  is  global  to  the  Iood  structure  and  hence  has  a value  after  loop 
termination  that  is  available.  If  no  data  unit  is  specified  as  the  loop 
control  variable  then  the  number  of  iterations  is  not  available  at  loop 
termination  as  no  loop  control  variable  is  used. 

If  the  loop  is  terminated  by  a GOTO  the  value  of  the  loop  control 
variable  (if  there  is  one)  is  available  unless  it  is  explicitly 
modified.  Modification  of  the  lanouage  to  make  loop  control  variables 
and  statement  names  within  the  loop  local  to  the  loop  (so  that  entry  is 
oermitted  only  at  loop  head)  would  require  a moderate  modification  to 
the  scope  rules  and  their  implementation  mechanisms.  See  the  comments 
under  FI. 


65.  Recursive  as  well  as  nonrecursive  routines  will  be 
available  in  the  source  language.  It  will  not  be  possible  to 


define  procedures  within  the  body  of  a recursive 
procedure.  ....F 

No  recursive  procedures  within  recursive  procedures  N/A 

(Maximum  depth  of  recursion  can  be  specified)  .N/A 

(Recursiveness  must  be  specified)  N/A 


The  languaqe  does  not  permit  recursion. 

Procedure  linking  in  present  implementations  of  the  language  is 
accomplished  without  the  use  of  a procedure  linking  mechanism.  The 
return  address  tor  the  callina  procedure  is  saved  in  the  called 
procedure.  Since  there  is  no  data  that  is  local  to  a procedure  (except 
for  local  indexes)  there  is  no  data  allocation  or  management  that  must 
be  performed  with  each  procedure  call.  These  features  permit  CMS-? 
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programs  to  execute  without  requiring  the  overhead  of  a monitor  or 
operating  system.  If  the  lanauage  were  modified  to  permit  procedures  to 
he  recursive,  an  external  procedure  linking  mechanism  with  a stack  for 
the  returns  and  for  data  that  must  be  preserved  (such  as  local  indexes 
and  loop  control  variables)  would  be  required.  Without  ehanginq  the 
scope  rules  to  comply  with  requirements  of  Section  F,  the  external 
procedure  linkinq  mechanisms  to  provide  recursion  would  be  a minor 
addition  to  the  present  implementation.  However,  recursion  without 
variables  local  to  the  procedure  may  not  be  of  much  value.  If  the  scope 
rules  ore  changed  a more  extensive  redesign  effort  would  be  required. 


G6  . The  source  lanauaqe  will  provide  a parallel  processinc 
capablity.  This  capability  should  include  the  ability  to 
create  and  terminate  (possible  pseudo)  parallel  processes  and 
for  these  orocesses  to  pain  exclusive  use  of  resources  during 


specified  portions  of  their  execution.  ....F 

Able  to  create  and  terminate  parallel  processes  ................. F 

Process  can  gain  exclusive  use  of  resources  F 

No  parallel  routines  within  recursive  routines  F 

No  routines  within  parallel  routines  F 

Maximum  number  of  simultaneous  instances  are  declarable  F 

(Access  rules  are  enforced)  F 


CMS-?  provides  no  capabilities  for  parallel  processing. 

Extensive  modifications  to  the  language  would  be  required  to 
include  parallel  processing  capabilities. 


G7 . The  exception  handling  control  structure  will  permit  the 
user  to  cause  transfer  of  control  and  data  for  any  error  or 


exception  situation  which  miqht  occur  in  a program.  ,...P- 

Program  can  get  control  for  any  exception  F 

Parameters  can  be  passed .P 

Can  get  out  of  any  level  of  a nest  of  control  F 

Can  handle  the  exception  at  any  level  of  control  F 


The  only  exception  handling  capabilities  provided  for  in  the 
language  are  the  abnormal  exit  parameter  (see  C7),  the  overflow 
detection,  the  parity  check,  and  the  ranqe  check  on  an  item  index  into  a 
table. 
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The  evaluation  of  an  arithmetic  exoression  in  an  assion  operation 
can  he  tested  for  overflow  and  control  transferred  to  a label.  (SFT 
<data  urit>  TO  <expression>  OVFRFLOW  <label>  s). 


The  Poolean  condition  in  a conditional  control  statement  can  oe  a 
test  for  odd  or  even  parity  on  any  data  unit  (contained  in  one  »ord) . 
(IF  <data  unit>  EVFNP  (or  ODDP)  THEN  ...) 


The  Boolean  condition  in  a conditional  control  statement  car  be  a 
test  that  an  item  index  into  a table  is  within  ranpe.  (IF  <table  index > 
VALID  (or  INVALID)  THEN  ...). 


The  extensions  tc  the  compiler  necessary  to  provide  a general 
purpose  exception  handling  control  structure  would  be  moderate. 


G8.  There  will  be  source  language  features  which  permit 
delay  on  any  control  path  until  some  specified  time  or 
situation  has  occurred,  which  permit  specification  of  the 
relative  priorities  among  parallel  control  paths,  which  give 
access  to  real  time  clocks,  which  permit  asynchronous 
hardware  interrupts  to  be  treated  as  any  other  exception 
s i tuat ion.  ....F 


Priority  specification  F 

Synchronization  via  wait/enable  operations  F 

Wait  for  end  of  real  time  interval  .F 

Wait  for  end  of  simulated  time  interval  .........................  f 

wait  for  hardware  interrupt  .......F 

(Can  enable  and  disable  interrupts)  F 


None  of  these  control  features  are  provided  tor  in  the  languaqe. 

A moderate  extension  to  the  language  would  be  required 
incorporate  these  features. 
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Hi.  The  source  language  will  be  free  format  with  an  explicit 
statement  delimiter,  will  allow  the  use  of  mnemonical ly 
significant  identifiers,  will  be  based  on  conventional  forms, 
will  have  a simple  uniform  and  easily  parsed  grammar,  will 
not  provide  unique  notations  for  special  cases,  will  not 
permit  abbreviation  of  identifiers  or  key  words,  and  will  be 


syntactically  unambiguous.  ....P 

Free  format  with  statement  terminator  T 

Mnemonic  identifiers  possible  ........ . ..........................  T 

Based  on  conventional  forms  .P 

Simple  grammar  P 

No  special  case  notations  p 

No  abbreviations  of  identifiers  or  keywords  .................... .P* 

Unambinuous  grammar  ...................................... .......P 


The  language  is  free  format.  All  statements  must  terminate  with  a 
'S'.  Identifiers  can  be  from  one  to  eight  alphanumeric  characters. 

with  some  exceptions  the  language  is  based  on  conventional  forms: 
Assignment  is  SET  <data  unit>  TO  <expression>  s,  the  case  statement  uses 
the  keyword  FOR. 

The  nrammer  is  simple  for  the  commonly  used  features.  However 
there  are  many  special  purpose  and  seldom  used  features  each  with  it 
own  syntax.  Complicated  expressions  involvino  Boolean  operators  and 
relational  expressions  can  be  unclear.  There  are  some  features  that  are 
context  dependent.  For  example,  arithmetic  expressions  in  EQUALS 
substitution  declarations  are  evaluated  using  a different  set  of 
precedence  rules  than  those  used  for  the  evaluation  of  other  arithmetic 
expressions . 

The  language  could  be  changed  easily  to  remove  the  seldom  used 
features  and  special  uses  and  to  resolve  the  ambiguities.  The 
implementation  of  these  changes  would  be  a modest  effort. 


H 2.  The  user  will  not  be  able  to  modify  the  source  language 
syntax.  Specifically,  he  will  not  be  able  to  modify  operator 
hierarchies,  introduce  new  precedence  rules,  define  new  key 
word  forms  or  define  new  infix  operator  precedences. 


T 


The  user  cannot  modify  the  syntax  of  the  language.  However, 
injudicious  use  of  the  means  text  substitution  mechanism  may  haye  the 
appearance  of  syntax  modification.  For  example,  if  an  entire  statement 
is  substituted,  the  substitution  name  would  have  the  appearance  of  a 
procedure  call.  Since  a substitution  name  is  not  easily  distinguishable 


% Vi 
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from  a procedure  name  the  use  of  MEANS  text  substitution  can  add  to  the 
visual  ambinuity  of  the  lanquaqe. 

The  MEANS  text  substitution  mechanism  can  be  easily  modified  so 
that  the  substitution  name  can  be  easily  distinouishea  from  any  other 
name  by  including  a special  signifying  character  in  substitution  names. 


H3 . The  syntax  of  source  lanquaqe  procrams  will  be 
comrosable  from  a character  set  suitable  for  publication 
purposes,  but  no  feature  of  the  lanouage  will  be  inaccessible 
usinc  the  64  character  ASCII  subset.  ....T 


CMS-?  uses  the  64  character  ASCII  subset. 


H4.  The  language  definition  will  provide  the  formation  rules 
for  identifiers  and  literals.  These  will  include  literals 
for  numbers  and  character  strings  and  a break  character  for 


use  internal  to  identifiers  and  literats.  ....T 

break  character  exists  .F 

(Literals  are  se If-identi f yinc  as  to  type)  .........P 

(Pit-string  literals  for  any  tyoe)  F 


(1)  Identifiers  are  formed  by  one  to  eight  alphanumeric  characters. 


The  first 

permitted. 

character 

must 

be  alphabetic. 

No 

break 

character 

is 

(?)  a. 

Character 

strino 

literals  are 

formed 

by 

enclosing 

the 

string  in  parentheses  and  preceding  the  literal  by  an  ‘H1,  e.g.,  h(A9C). 
Separate  ouoting  of  each  line  of  a long  literal  is  not  required:  HCTH1S 
IS  A LONG  LITERAL  STRING).  Any  break  character  could  be  used  since  the 
literal  is  enclosed.  It  would  be  interpreted  as  part  of  the  character 
string  literal. 

b.  Numeric  literals  may  be  octal  or  decimal.  In  the  default 
compiler  mode  octal  numbers  must  be  enclosed  in  parentheses  and  preceded 
by  the  letter  0.  All  numbers  not  enclosed  in  parentheses  are  assumed  to 
be  decimal.  The  compiler  mode  may  be  declared  to  be  octal,  in  which 
case  all  decimal  numbers  must  be  enclosed  in  parentheses  and  preceded  oy 
a D (or  may  be  unenclosed  and  suffixed  by  a 0).  All  other  numbers  are 
assumed  to  be  octal.  All  numbers  may  contain  an  optional  radix  point 
and  may  be  expressed  in  scientific  CE')  notation.  No  break  character 
is  permitted. 
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A break  character  of  space,  underline,  or  tilde  could  be  used  with 
any  of  the  numeric  literals.  Only  a minor  modification  to  existing 
implementations  would  be  required. 

A break  character  of  space  could  not  be  used  with  identifiers 
without  introducing  syntactic  ambiguities  into  the  language.  Any  break 
character  to  be  used  with  identifiers  would  not  be  of  much  value  unless 
identifiers  could  be  formed  from  some  number  of  characters  significantly 
larger  than  eight.  Adding  this  feature  to  the  language  would  reauire  a 
restr jctur ing  of  the  symbol  table  in  existing  compilers,  thereby 
reducina  the  number  of  symbols  available  to  the  user. 


H5.  There  will  be  no  continuation  of  lexical  units  across 
lines,  but  there  will  be  a way  to  include  object  characters 
such  as  end-of-line  in  literal  strings.  ....F 


The  language  permits  lexemes  to  continue  across  lines. 

This  capability  could  be  removed  with  a relatively  minor 
modification  to  existing  implementations.  However,  a break  character 
must  be  provided  for  long  character  string  literals. 


H6 . key  words  will  be  reserved,  will  be  very  few  in  number, 
will  be  informative,  and  will  not  be  usable  in  contexts  where 
an  identifier  can  be  used.  ....P 


The  language  has  179  primitives  (or  key  words).  A primitive  cannot 
be  assigned  as  an  identifier  (i.e.,  the  primitive  is  reserved)  if 
ambiguities  would  be  created  in  the  user»s  program.  There  are  29 
primitives  that  cannot  create  ambiguities  and,  therefore,  are  not 
reserved. 

Making  all  primitives  reserved  would  require  a simple  modification 
to  the  existing  implementation. 

The  large  number  of  primitives  in  the  language  is  indicative  of  the 
variety  of  syntax  available.  The  number  of  primitives  could  be  reduced 
by  removing  from  the  lanouaoe  those  control  mechanisms  that  are 
redundant  or  seldom  used. 
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H7 . The  source  language  will  have  a single  uniform  comment 
convention.  Comments  will  be  easily  distinguishable  from 
code,,  will  be  introduced  by  a single  (or  possibly  two) 
lanouage  defined  characters,  will  permit  any  combination  of 
characters  to  appear,  will  be  able  to  appear  anywhere 
reasonable  in  programs,  will  automatically  terminate  at 


end-of-line  if  not  otherwise  terminated,  and  will  not 
prohibit  automatic  reformatting!  of  programs.  ....H 

Uniform  comment  convention  F 

Lock  different  from  code  U 

Bracketed  by  one  or  two  characters  ............................. .P 

Can  contain  any  characters  ......T 

Can  apoear  anywhere  reasonable  T 

Terminated  by  the  end  of  the  line  ...............................  F 

Compatible  with  automatic  reformattino  ...T 


The  language  has  three  comment  conventions: 

(1)  Comment  statement:  COMMENT  <strinq>  t The  comment  statement 
cannot  appear  within  any  other  statement. 

(?)  Bracket  notes:  Used  to  document  one  of  the  five  bracket 
declarations  (system  declaration,  system  data  declaration,  system 
procedure  declaration,  head  declaration,  and  local  data  declaration) 
<dec lar at ion><strina>  t. 

(3)  Notes:  strings  delimited  by  pairs  of  consecutive  single  primes. 
They  may  appear  in  any  statement  wherever  it  is  permissible  to  use  a 
space.  • *<strina>» » . 

Since  the  notes  convention  could  accomplish  the  functions  of  the 
other  two  comment  conventions  it  is  not  necessary  to  have  more  than  one. 
The  other  two  conventions  could  be  removed  easily  from  the  languaoe  with 
no  imoact  on  existing  implementations. 


H8.  The  lanquage  will  not  permit  unmatched  parentheses  of 
any  kind.  ....T 


The  language  does  not  permit  unmatched  parentheses. 


There  will  be  a uniform  referent  notation 


p + 


A 


C*»S-2  34 

Requirement  M9 


Almost  all  function  calls  and  array  element  references  use  the  same 
notation.  The  only  exceptions  are  the  two  intrinsic  functions  EIT  and 
CHAR.  It  can  be  argued  that  BIT  and  CHAR  are  not  functions  in  the 
normal  sense  that  the  term  is  used,  but  rather  operators  or  modifiers. 

Subsequent  versions  of  CMS-2  have  adopted  the  uniform  function 
notation  for  BIT  and  CHAR.  This  has  required  only  a minor  modification 
to  the  language  and  has  had  a reverse  impact  on  the  implementation. 
That  is,  implementation  for  subsequent  versions  required  less  code  since 
one  fewer  syntactic  form  was  necessary. 


Hi 0 . No  language  defined  symbols  appearing  in  the  same 
context  will  have  essentially  different  meanings.  ....P 


There  are  several  areas  in  the  lanouage  where  the  meaning  of  a 
symbol  is  context  dependent: 

(1)  AND,  OR  and  COWP  are  used  both  as  logical  connectors  between 
Boolean  expressions  and  as  hit  string  operators  (e.g.,  X AND  Y results 
in  the  bit  by  bit  logical  AND  of  X and  Y).  This  dual  use  has  createo 
problems  of  ambiguity 

(2)  THEN  is  used  both  as  a statement  connector  (<statement>  THEN 
<statement>)  and  in  the  conditional  control  structure  (IF  <expression> 
THEN  ...  ELSE). 

(3)  The  symbol  period  is  used  both  as  a label  terminator  and  as  a 
radix  point.  In  addition,  two  periods  is  used  for  the  scaling  specifier 
and  three  periods  is  used  to  indicate  a series  of  consecutive  items  in 
an  INPUT  or  OUTPUT  statement. 

(4)  There  are  three  types  of  EQUALS  dec  larations : numeric  constant, 
the  difference  between  the  allocations  of  two  addressable  names,  and  the 
allocation  of  an  addressable  name.  The  type  of  EQUALS  is  dependent  on 
the  evaluation  of  the  expression  in  the  declaration.  In  addition,  the 
expression  is  evaluated  left  to  riqht  with  no  hierarchy  of  operators. 
Numeric  expressions  in  other  contexts  are  evaluated  hierarchically. 

Elimination  of  any  of  these  multiple  purpose  syntactic  forms  would 
require  the  introduction  of  new  syntactic  forms.  In  each  case  there 
would  be  no  impact  on  other  requirements  and  only  minor  modifications  to 
the  present  implementations  would  be  necessary. 


W 
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II.  There  will  be  no  defaults  in  programs  which  affect  the 
program  logic.  That  is,  decisions  which  affect  proaram  Ionic 
will  be  made  either  irrevocably  when  the  language  is  defined 
or  explicitly  in  each  program.  ....T 


There  are  no  implementation  defaults  that  affect  program  Ionic. 


12.  Defaults  will  be  provided  for  special  capabilities 
affecting  only  object  representation  and  other  properties 


which  the  programmer  does  not  know  or  care  about.  Such 
defaults  will  always  mean  that  the  programmer  does  not  care 
which  choice  is  made.  The  programmer  will  be  able  to 
override  these  defaults  when  necessary.  ....P 

Defaults  specified  for  don't  care  cases  .T 

Programmer  can  override  the  defaults  P 


The  language  includes  defaults  that  affect  only  object 
representation,  these  include: 


(1)  Data  representation:  table  packino  - the  user  may  define  the 

internal  position  of  each  field  cr  he  may  let  the  compiler  determine  the 

most  optimal  internal  arrangement  of  the  fields  according  to  one  of 

three  user  specified  packing  modes. 

« 

« 

(2)  Function/subroutine  calls:  intrinsic  functions  may  be  either 
open  or  closed  dependent  on  the  input  parameters.  For  example,  the  PIT 
modifier  is  open  if  the  bit  strina  specified  does  not  cross  a word 
boundary;  it  is  closed  otherwise. 


(3)  Reentrant  vs  nonreentrant:  the  user  may  indicate  that  the  code 
is  to  be  reentrant.  If  not  specified,  the  code  is  nonreentrant.  Data 
for  reentrant  code  may  be  specified  so  that  multiple  copies  are 
generated . 


Function/subroutine  calls:  to  provide  the  additional  capability  for 
the  user  to  be  able  to  specify  whether  the  function  is  open  or  closed 
would  require  major  code  additions  to  existing  implementations. 


13.  The  user  will  be  able  to  associate  compile  time 
variables  with  programs.  These  will  include  variables  which 
specify  the  object  computer  model  and  other  aspects  of  the 


! 


i 
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object  machine  configuration. 


..P- 


The  only  compile  time  capability  available  to  the  user  is  the 
CSWITCH.  CSWITCH  brackets  allow  sections  of  proorams  to  be  selectively 
compiled.  The  CSWITCH  is  set  outside  the  prooram  but  is  not  available 
for  interrogation  within  the  program  by  the  user.  Other  compile  time 
information  such  ?s  the  presence  of  the  operating  system,  are  available 
only  to  the  compiler  and  not  to  the  user. 

Inclusion  of  other  compile  time  variables  would  require  a major 
extension  to  the  compiler. 


14.  The  source  language  will  permit  the  use  of  conditional 
statements  (e.g.,  case  statements)  dependent  on  the  object 
environment  and  other  compile  time  variables.  In  such  cases 
the  conditional  will  be  evaluated  at  compile  time  and  only 
the  selected  path  will  be  compiled.  ....P- 


Conditional  compilation  is  provided  for  only  with  the  CSWITCH.  See 
the  comments  under  requirement  13. 


15.  The  source  languaqe  will  contain  a simple  clearly 
identifiable  base  or  kernel  which  houses  all  the  power  of  the 
language.  To  the  extent  possible,  the  base  will  be  minimal 
with  each  feature  providing  a single  unique  capability  not 
otherwise  duplicated  in  the  base.  The  choice  of  the  base 
will  not  detract  from  the  efficiency,  safety,  or 
understandabi l ity  of  the  language.  ....F 


The  base  of  the  language  is  the  entire  language  and  it  is  not 
small.  There  are  no  extension  features  for  defining  new  capabilities  in 
terms  of  the  base. 

The  base  of  the  language  could  be  reduced  to  provide  a relatively 
low  level  general  purpose  capability  merely  by  removinq  those  seldom 
used  and  special  case  features. 
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16.  Lanquage  restrictions  which  are  dependent  only  on  the 
translator  and  not  on  the  object  machine  will  be  specified 
explicitly  in  the  language  definition. 


P ♦ 


limits  on  the  number  of  array  dimensions,  the  lenqth  of 
identifiers,  the  number  of  nested  parentheses  levels  and  the  number  of 
nested  block  levels  are  part  of  the  lanquage  definition.  The  number  of 
identifiers  in  a proaram  however,  is  not  part  of  the  language  definition 
and  is  not  fixed  by  the  translator  but  is  limited  by  the  amount  of  core 
storage  available  on  the  AN/UYK-7  system  that  hosts  the  compiler. 

Changing  the  limit  on  the  number  of  identifiers  in  a program  to  a 
languane  defined  limit  would  require  a simple  modification  to  the 
existing  translator. 

The  limits  on  array  dimensions,  the  number  of  nested  parentheses 
levels  and  the  number  of  nested  block  levels  are  set  so  high  that  no 
program  should  encounter  the  limits.  The  length  of  identifiers, 
however,  could  be  considered  by  many  to  be  arbitrarily  short.  See  the 
comments  on  requirement  HA  for  the  scope  and  impact  of  modifications  of 
this  limit. 


I 


17.  Language  restrictions  which  are  inherently  dependent 
only  on  the  object  environment  will  not  be  built  into  the 
language  definition  or  any  translator. 


T 


Restrictions  such  as  amount 
specialized  peripheral  equipment, 
definition. 


of  run  time 
etc.  are  not 


storage,  access  to 
part  of  the  language 
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J1 . The  language  and  its  translators  Mill  not  impose  run 
time  costs  for  unneeded  or  unused  generality.  They  Mill  be 


capable  of  producing  efficient  code  for  all  programs.  ....U 

No  efficiency  cost  for  unused  features  U 

Efficient  code  can  be  produced  for  all  features  ..........U 


The  current  implementation  of  the  language  attempts  to  qenerate 
efficient  code  for  the  widest  variety  of  programs:  Sophisticated 
optimization  techniques  are  used;  for  common  special  uses  the  compiler 
generates  special  sequences  of  code  rather  than  standard  sequences  for 
all  cases;  only  the  run  time  support  routines  required  by  the  program 
become  part  of  the  program.  However,  certain  trade-offs  exist  within 
the  compiler  and  it  is  not  possible  to  ascertain  that  the  most  efficient 
code  is  generated  for  all  programs.  For  example,  certain  features 
always  use  a run  time  support  routine.  There  are  probably  some 
infrequently  occurring  special  cases  of  these  features  for  which 
generation  of  in-line  code  would  be  more  efficient. 


J2.  Any  optimizations  performed  by  the  translator  will  not 
change  the  effect  of  the  Drogram.  ....T 


Optimization  by  the  compiler  does  not  change  the  effect. 


J3.  The  source  language  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  including  machine 
language  code  insertions.  ....T 


Machine  language  insertions  are  permitted  in  CMS-2  programs  in  data 
designs  and  procedures  provided  the  insertions  are  bracketed  with  the 
statements  DIRECT  S and  CMS-?  S.  The  machine  language  is  equivalent  to 
AN/UY K-7  assembly  language. 


J4 . It  will  be 
specify  the  object 
These  descriptions 
be  distinct  from 


possible  within  the  source  language  to 
presentation  of  composite  data  structures, 
will  be  optional  and  encapsulated  and  will 
the  logical  description.  The  user  will  he 
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able  to  specify  the  time/space  trade-off  to  the  translator. 
If  not  specified,  the  object  renresentat ion  will  be  optimal 


as  determined  by  the  translator.  ....P+ 

Fncapsulated  specification  of  representation  possible  ...........p 

Space/time  tradeoff  can  be  specified  ........................... ,P+ 


The  lanquage  provides  the  user  with  the  capability  of  specifying 
the  ooject  representation  of  the  items  of  tables  (records  of  arrays). 
The  user  can  either  pack  the  fields  himself  by  defining  the  size  and 
arrangement  of  the  fields  in  the  table  or  he  can  indicate  hew  the 
compiler  is  to  pack  the  fields  by  specifying  a packing  descriptor  (NOME , 
MEDIUM  or  DFNSF)  with  the  table  declaration.  The  packing  descriotor 
NONF  signifies  that  the  compiler  is  to  allocate  the  maximum  snace  (and, 
therefore,  least  execution  is  reauired).  DENSE  signifies  the  least 
snace  (and,  hence,  most  execution).  In  addition  to  the  packing 
descriptor  the  user  can  further  control  the  arrangement  of  fields  within 
user  packed  tables  by  usinci  the  field  overlay  capability  (free  union). 

With  either  user  packinq  or  compiler  packincs  the  user  does  not  have 
complete  control  over  the  arrangement  of  fields  within  the  taole.  A 
field  may  not  start  in  the  middle  of  one  word  and  end  in  the  middle  of 
another  word,  and  multi-word  fields  must  end  on  a word  toundary. 

For  user  packed  tables  the  startinq  word  and  startinq  hit  of  each 
field  is  not  encapsulated  but  is  additional  information  appended  to  the 
field  description. 

All  of  the  fields  within  a table  must  be  either  user  packed  or 
compiler  packed.  User  packino  and  compiler  packinq  cannot  be  mixed 
within  a table. 

Expansion  of  the  user's  control  over  object  representation  o*  items 
of  tables  by  allowina  mixed  user  packing  and  compiler  packinq,  or  adding 
new  packing  descriptors,  etc.  would  require,  in  addition  to  syntax 
revisions,  a modification  of  the  packinq  algorithms.  Giving  the  user 
complete  control  over  the  positioning  of  fields  over  word  boundaries 
would  require  new  codinq  sequences  and/or  additional  run  time  routines. 


J5.  The  programmer  will  be  able  to  specify  whether  calls  on 
a routine  are  to  have  an  ooen  or  closed  implementation.  An 
open  and  a closed  routine  of  the  same  description  will  have 


identical  semantics.  ....F 

Open/closed  properties  can  be  specified  ......................... F 

Open  and  closed  versions  have  the  same  semantics  .F 


CHS-? 

Requirement  J5 


40 


* 

»ll  user  defined  procedures  and  functions  are  closed. 

The  current  implementation  of  the  translator  could  be  retrofitted 
to  include  the  capability  of  open  user  defined  procedures /funct ions 
without  requiring  a major  redesign.  However.,  additional  storage  in  the 
symbol  table  would  be  required  to  save  the  open  procedure/function  for 
later  expansion,  thereby  reducino  the  number  of  symbols  available  to  the 
user  . 


I 
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Extraneous  Features 

We  recommend  that  the  followina  features  of  CMS-?,  not  required  by 
the  Tinman,  be  kept: 

* Character  string  type  (assuming  that  the  Tinman 
requires  only  a character  type,  not  a character  strinn 
type)  and  the  concatenation  operator,  CAT. 

* Result  parameters  (OUTPUT  parameters)  for  procedures. 

* Control  of  the  internal  structure  of  tables  (arrays) 
throuqh  (1)  specifyina  the  internal  arrangement  of  the 
records  of  a simple  tatle  (one-dimensional  array)  as 
either  horizontal  or  vertical  and  (?)  specifyina  the 
compiler  packing  algorithm  to  be  used. 

* The  ability  to  declare  system  procedures  (modules)  tc 
be  reentrant. 


The  following  features  provide  a useful  capability  to  the  CMS-? 
user  community.  They  should  be  either  kept  intact  or  replaced  by  some 
equivalent  feature: 

* Bit  string  type.  A datum  of  any  of  the  atomic  types 
can  be  converted  to  a bit  striny  by  use  of  the  BIT 
functional  modifier. 

* The  debug  option.  This  capability  has  proved  useful 
and  could  even  be  expanded. 

* The  MEANS  statement  (temporary  source  substitution). 

This  could  be  included  in  a more  general  macro 
capabi l ity . 

* The  explicit  conversion  operators  PIT  and  CHAR,  which 
convert  data  to  bit  string  type  and  character  string 
type  respectively,  regardless  of  their  declared  type. 

* The  scaling  specifier  for  intermediate  computations  in 
fixed-point  expressions. 

* Multiple  receptacle  assignment  statements.  The  most 
common  use  for  this  feature  is  initialization  at  what 
would  be  the  beginning  of  a scope  in  a more  modern 
language . 

* Procedure  switches  (item  and  index).  Although  the 
same  effect  can  be  obtained  through  a combination  of  a 
FOR  (case)  statement  and  procedure  calls,  this  syntax 
enables  the  compiler  to  generate  code  which  is 
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efficient 
parameter 
of  this. 


in  both 
passage 


space  and  time,  particularly  it 
is  involved.  NT DS  takes  advantage 


The  following  features  are  highly  machine  dependent,  but  they  have 
been  found  useful  by  CNS-2  users.  They  should  be  retained  because  of 
this  user  interest,  but  they  should  be  reauired  to  be  bracketed 
(encapsulated)  by  statements  which  mark  them  as  being  machine  dependent 
(requirement  J3): 

* Designation  that  a procedure  parameter  is  to  be  passed 
in  a specific  machine  register. 

* Designation  that  a datum  is  to  reside  permanently  in  a 
machine  reqister  within  its  scope  of  definition 
(system  and  local  indexes).  This  might  even  be 
expanded  to  allow  various  data  types  to  reside  in 
these  registers;  currently  only  one  range  of  integer 
type  is  permitted. 

* The  shift  operators,  which  duplicate  the  machine  shift 
instructions. 

* The  stop  operators,  which  duplicate  the  machine  stop 
instructions.  A variant  of  this  capability  also 
occurs  in  the  RFTlJPN  statement. 

* The  COUNT  function,  which  counts  the  number  of  1-bits 
in  a data  unit. 

The  following  features  of  CPS-2,  not  required  by  the  Tinman,  should 
be  deleted: 

* The  EXCHANGE  statement  (permanent  source 
substitution).  This  is  actually  a function  of  a 
source  file  editor  and  should  not  be  in  the  language. 

* OVERLAY,  a form  of  tree  union. 

* Sub-tables  (declared  subdivisions  of  tables).  This 
has  most  of  the  bad  properties  of  free  union  with  very 
few  offsetting  virtues. 

* The  FIND  statement  (table  search).  This  is  simply  a 
replacement  for  a combination  of  a VARY  and  an  IF 
statement . 

* Statement  switches  (index  and  item).  These  are 
elaborations  of  the  GOTO  statements. 

* The  ability  to  specify  that  a floating  point  datum  is 
to  be  rounded.  This  is  too  hardware  dependent. 
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* The  PACK  statement.  This  is  tittle  used  and  is  almost 
useless  because  its  inverse  (UNPACK)  is  not  in  the 
language . 

* The  SWAP  statement.  This  is  too  little  used  to  be 
worthwhi  le . 

* Table  word  referencing,  which  permits  addressing  a 
machine  word  within  a table  (array).  This  is  too 
hardware  dependent,  thereby  seriously  inhibiting 
portability,  and  is  a means  of  defeating  type-check inc 
as  well. 
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Summary 

CMS-2  is  an  old  lanquage.  The  oriqinal  design  of  the  first  version 
of  the  language  was  influenced  by  its  predecessor  (CS-1),  the  language 
concerts  prevalent  in  the  mid-sixties,  and  its  first  target  machine  (the 
AN/USQ-20 > . Changes  to  the  lanquage  through  the  years  were  made 
primarily  by  the  addition  of  new  features  rather  than  by  revision.  The 
desion  of  the  version  of  CMS-2  being  evaluated  here,  CMS-2Y(7),  was 
influenced  Dy  its  predecessors,  retaining  most  of  their  features  and 
syntax,  and  by  its  target  machine,  the  AN/UYK-7.  The  growth  of 
CMS-2 Y (7)  has  been  primarily  by  the  addition  of  new  features.  The  most 
recent  growth  was  caused  by  the  current  flurry  over  structured 
oroar amminq. 

CMS-2  now  contains  most  of  the  structured  programming  features 
common  to  modern  hOLs : The  case  statement,  WHILE  and  UNTIL  conditions  on 
iteration,  block  structuring,  etc.,  in  addition  to  those  features  that 
were  considered  necessary  for  embedded  military  systems:  Machine  code 
insertions,  separate  element  compilation,  coirpools,  procedure  linkage 
without  a required  monitor,  mapping  of  structures  to  the  machine,  high 
level  access  to  machine  functions  and  hardware,  and  features  chosen  for 
their  high  efficiency  (both  in  execution  speed  and  space),  such  as  the 
procedure  switch.  Some  of  the  features  make  CMS-2  highly  machine 
dependent  and  are  contradictory  to  the  philosophy  of  DOD-1. 

As  one  would  expect  from  a language  that  is  an  amalgam  of  features 
advocated  by  different  schools  of  language  design,  there  are  some 
inconsistencies  and  context  dependencies,  although  through  careful 
design  these  have  been  keot  to  a small  number.  Similarly,  an  attempt 
has  been  made  to  avoid  unnecessary  complexity  of  the  syntax  and 
semantics.  Although  large,  the  language  is  not  unwieldy  or  difficult  to 
learn.  In  subsequent  versions  of  the  language  some  of  the  seldom  used 
features  have  been  culled  and  some  of  the  syntax  has  been  redefined  to 
resolve  inconsistencies  and  create  a more  uniform  notation. 

CMS-2  meets,  at  least  partially,  many  of  the  Tinman  requirements, 
primarily  those  that  would  be  met  by  most  high  order  languages  in 
current  use  for  military  systems.  It  has  a wide  variety  of  data  types 
and  structures,  including  records,  arrays,  and  fixed  point,  floating 
point,  character  string,  and  enumeration  types.  It  has  literals  for 
most  data  types  (not  for  Boolean,  however!)  and  allows  data 
initialization.  It  has  all  the  standard  arithmetic,  relational,  and 
logical  operators.  It  has  the  standard  control  structures:  Sequential, 
conditional,  iteration,  and  some  exception  handling.  It  is  free  form, 
allows  mnemonic  identifiers  and  labels,  has  adequate  commenting 
capabilities,  and  has  access  to  libraries.  It  has  functions  with 
multiple  inputs  and  procedures  with  multiple  input  and  output  (result) 
parameters. 

what  is  missing  from  the  lanquage  are  many  of  the  more  modern 
features  which  allow  a higher  degree  of  programming  sophistication. 
These  include  extension  capabilities,  recursion,  parallel  processing. 
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pointers,  generic  procedures,  and  suitable  I/O  capabilities  ana  scope 
rules.  The  I/O  capabilities  in  CMS-2  are  very  rudimentary,  designed 
primarily  for  batch  operation.  All  I/O  for  embedded  systems  is 
performed  using  machine  language  inserts  which  interface  with  special 
ouroose  executives  tailored  to  the  specific  application.  CMS-2  ^oes  not 
permit  the  scope  of  data  units  to  be  local  to  a procedure,  a block,  or  a 
control  structure. 

7 1 is  not  clear  that  usina  CMS-2  as  a starting  point  for  creation 
of  a DOD-1  language  would  be  the  most  expedient  approach.  It  sterns 
likely,  pending  more  precise  definitions  of  the  features  to  be  added, 
that  C«S-2  could  be  modified  to  more  closely  meet  the  Tinman 
requirements,  but  the  modifications  would  doubtlessly  be  extensive  and 
costly.  The  resultant  lanouaoe  probably  would  not  be  as  simple  ano 
concise  as  desirable.  fertainly  it  would  no  longer  be  CMS-?. 
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Introduction 

This  report  nives  a comparison  of  the  lanquage  CORAL  66  to  the 
Tinman  language  requirements  ^Department  of  Defense  Requirements  for 
High  Order  Computer  Programming  Languages,  "Tinman"  - 1 March  1976, 

Section  TV).  For  the  purposes  of  this  comparison,  CORAL  66  is 
considered  to  be  defined  by: 

Inter-Establishment  Committee  on  Computer 
Applications 

Official  Definition  of  CORAL  66 
Ministry  of  Defence 
Her  Majesty's  Stationary  Office 
London,  197P 


Tinman  contains  7 8 lancuaqe  requirements.  This  report  compares 
CORAL  66  to  each  requirement  individually.  If  a requirement  is  totally 
satisfied,  the  accompanying  text  is  a summary  of  the  particular 
mechanism  used.  (Occasionally  no  text  is  needed  if  a requirement  is 
totally  satisfied.)  If  a requirement  is  not  totally  satisfied,  the  text 
consists  of  a summary  of  the  shortcomings  and  such  items  as  the  scope  of 
the  changes  necessary  to  fully  meet  the  requirement  and  the  impact  of 
these  changes  on  existing  implementations. 

Each  Tinman  requirement  becins  with  an  introductory  paraaranh. 
These  paragraphs  are  reproduced  in  this  report.  In  many  cases  they  are 
followed  by  several  sinrle-line  summaries  of  features  in  the  area  of  the 
requirement.  Usually  these  are  features  which  are  specifically  called 
for  in  the  requirement.  A feature  enclosed  in  parentheses,  however,  is 
one  which  the  reviewers  thought  rossibly  desirable,  even  thouah  not 
called  for  in  the  requirement. 

Symbols  placed  beside  the  introductory  paragraph  and  the  individual 
features  indicate  the  degree  to  which  the  requirement  or  feature  is 
satisfied  by  the  lanouage.  The  symbols  and  their  meanings  are: 

T - Totally  satisfied 

P - Partially  satisfied 

F - Fails  (not  satisfied  at  all) 

U - Unclear  from  the  documentation 

P*  - Almost  totally  satisfied 

P-  - Only  slightly  satisfied 

N/A  - Not  applicable  (used  only  for  indiviaual 
features  when  the  requirement  is  not  satisfied 
at  all) 
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(The  symbols  P,  P*,  and  F-  will  often  be  used  with  requirements  which 
are  stated  in  one  of  the  forms  "There  will  be  no..."  or  "All...",  even 
though  only  T or  F are  technically  applicable  in  these  cases.) 

The  report  concludes  with  two  summaries.  The  first  is  cf  the 
features  of  CORAL  66  which  are  extraneous  to  Tinman  and  the  desirability 
of  retaining  each  of  them.  The  second  is  of  the  language  as  a whole  and 
the  desirability  of  modifying  it  to  bring  in  into  line  with  the  Tinman 
requi rements . 
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I 

A 1 . The  language  will  be  typed.  The  type  (or  mode)  of  all 
variables,  components  of  composite  data  structures, 
expressions,  operations,  and  parameters  will  be  determinable 
at  compile  time  and  unalterable  at  run  time.  The  language 
will  require  that  the  type  of  each  variable  and  component  of 
composite  data  structures  be  explicitly  specified  in  the 
source  programs.  ....T 


CORAL  66  requires  an  explicit  speri f ication  of  the  tyre  of  each 
variable  and  component  of  data  tables.  Although  it  allows  implicit 
conversions  during  expression  evaluations,  the  type  or  node  of 
evaluation  is  determined  at  compile  time  and  does  not  chenae  at  run 
time. 


A 2 . The  language  will  provide  data  tynes  for  irteger,  real 
(floating  point  and  fixed  point),  boolean  and  character  and 
will  provide  arrays  (i.e.,  composite  data  structures  with 
indexable  components  of  homogeneous  tyre)  and  records  (i.e., 
composite  data  structures  with  labeled  components  of 
heterogeneous  type)  as  tyre  generators.  ...,P+ 


Integer  T 

Floating  Point  .P* 

Fixed  Point  T 

Boolean  ...................................F 

Character  String  ........P 

Arrays  T 

Records  ...........T 


COPAL  66  provides  for  integer,  floating,  fixed,  and  array  type  of 
data  hut  does  not  provide  for  Roolean  variables.  The  official 
definition  of  the  lanouage  does  not  allow  character  data  declarations 
but  Rlandford  extensions  to  CORAL  66  permit  RYTE  declarations  which  ar 
used  for  character  definitions  and  strinq  manipulations.  The  TABLF 
declaration  allows  the  definition  of  the  tyoe  of  a table's  components 
including  their  width  and  lenoth.  This  is  equivalent  to  defining  a 
record.  The  implementation  of  floating  point  is  optional  and  is 
dependent  upon  the  hardware.  If  the  computer  does  not  have  the  floating 
ooint  unit,  this  feature  is  not  required. 

Introduction  of  Boolean  type  variables  will  require  changes  to 
existing  implementations  in  tyre  checking,  table  declarations, 
comparison  operations,  function  and  procedure  parameter  definitions  etc. 
The  floating  point  type  data  definitions  can  be  made  mandatory  since 
this  feature  can  be  provided  by  software  at  the  cost  of  some  storage 
space.  This  may  be  significant  on  mini  computers,  but  will  cause 


ft  S 
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Tinimal  problems  on  larger  computers.  The  Blandford 
merged  with  the  languaae  kernel  and  made  cart 
definition,  instead  of  being  left  as  en  extension. 


extension 
of  the 


can  he 
official 


A3.  The  source  language  will  recuire  global  (to  a scope) 
specification  of  the  precisicn  for  floating  point  arithmetic 
and  will  permit  precision  specification  for  individual 
variables.  This  specification  will  be  interpreted  as  the 
maximum  precision  required  by  the  program  logic  and  the 
minimum  precision  to  be  supported  by  the  object  code. 


Global  arithmetic  precision  specification  mandatory  F 

Individual  variable  precision  specification  permitted  T 


CORAL  66  does  not  allow  olobal  specification  of  the  precision  for 
floating  point  arithmetic.  In  fact  it  permits  no  precision 
specification  at  all  for  floatina  point  numbers.  They  are  confined  to 
one  full  word. 

The  language  does  permit  individual  precision  specification  for 
fixed  point  numbers  and  thus  meets  the  second  oart  of  this  reouirement. 

To  meet  this  requirement  the  language  will  have  to  be  modified  in 
following  ways:  (1)  Implementation  of  floating  point  data  will  have  to 
be  made  mandatory,  (2)  the  syntax  of  the  language  and  the  data 
definition  will  have  to  be  modified  to  permit  specification  of  precision 
by  the  user , and  (3)  global  specification  of  precisior  for  floating 
computations  will  have  to  be  allowed. 

These  changes  to  the  lanouage  will  impact  alt  existing 
implementations  since  none  of  them  permits  global  specification  of 
precision  for  floating  numbers.  Besides,  many  existina  implementations 
do  not  have  the  floating  point  option  at  all. 


A4 . Fixed  point  numbers  will  be  treated  as  exact  quantities 
which  have  a range  and  a fractional  step  size  which  are 
determined  by  the  user  at  compile  time.  Scale  factor 
management  will  be  done  by  the  compiler.  ....r* 


Treated  as  exact  quantities  

Ranqe  and  step  size  determined  at  compile  time 
Scaling  handled  automatically  ................ 


T 

P 

p 
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The  requirement  implies  that  the  user  should  be  able  to  specify 
explicitly  the  range  and  step  size  of  the  fixed  point  numbers.  CORAL  66 
allows  the  user  to  specify  the  total  bits  and  the  fraction  bits 
associated  with  a fixed  point  number,  thus  implicitly  setting  the 
possible  range  of  values  and  the  step  size,  but  does  not  allow  an 
explicit  declaration  to  do  so.  Furthermore,  it  dies  not  allow  the 
number  to  exceed  one  full  word  of  the  computer,  thus  making  the  fixed 
ooint  data  definition  and  its  rer.ge  machine  denerdent.  Scaling  for  each 
variable  is  specified  by  the  user,  but  is  automatically  handled  Dy  the 
compiler  while  processing  expressions.  Thus  the  language  only  partiallv 
meets  this  overall  requirement. 

The  language  definition  should  be  modified  to  allow  th*»  user  to 
specify  the  ranqe  and  step  size  of  fixed  point  variables.  Furthermore, 
the  language  should  not  restrict  the  size  of  a fixed  point  variable  to 
one  computer  word.  The  user  should  control  the  size  of  the  word  and  its 
range  and  not  the  computer  word  size  or  the  compiler. 

Such  modifications  to  the  languaqe  will  impact  all  existing 
implementations  significantly  since  they  all  provide  for  one  computer 
word  to  define  a fixed  point  and  floatinq  point  number. 


A5 . Character  sets  will  be  treated  as  any  other  enumeration 


tyre . . . . . F 

New  sets  can  be  defined  as  enumeration  types  ..F 

ASCII  and  EBCDIC  are  provided  F 

(Conversion  carability  between  sets  is  available)  F 


COPAL  66  does  not  permit  definition  of  a user-specified  character 
set.  The  character  set  is  defined  to  be  ISO  (Same  as  ASCII). 
Furthermore,  no  facilities  are  provided  in  the  lanouage  to  alter  the 
collating  sequence  of  these  characters  at  compile  time.  The  conversion 
capabilities  between  EBCDIC  and  ASCII  arc  dictated  by  implementations 
and  net  required  by  the  language  definition.  Thus  CORAL  66  fails  to 
meet  this  requirement. 

s 

Introduction  of  a capability  to  enumerate  a character  set  in  CORAL 
66  is  a major  language  desicn  change  having  an  eaually  significant 
effect  upon  implementation,  it  would  require  adding  status  variables 
and  enumeration  capabilities  which  the  language  does  not  presently  have. 

Changes  in  the  language  to  accommodate  user  defined  character  sets 
will  require  modification  to  all  existing  implementations.  The  library 
will  have  to  include  routines  to  convert  ASCII  to  EBCDIC  and  other 
installation  and  implementation  related  conversion  routines. 
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Other  features  of  the  language  related  to  strings  and  character 
sets  will  also  be  affected  to  accommodate  the  programmer-defined 
character  set. 


A 6 . The  language  will  require  user  specification  of  the 
number  of  dimensions,  the  range  of  subscript  values  for  each 
dimension,  and  tyre  of  each  array  component.  The  number  of 
dimensions,  the  type  and  the  lower  subscript  bound  will  be 
determinable  at  compile  time.  The  upper  subscript  bound  will 


be  determinable  at  entry  to  the  array  allocation  scope.  ....P+ 

Number  of  dimensions  is  fixed  at  compile  time  T 

Tyoe  is  fixed  at  compile  time  T 

Lower  subscript  bound  is  fixed  at  compile  time T 

Upper  subscript  bound  is  fixed  at  scope  entry  F 

Subscripts  only  integers  or  from  an  enumeration  type  T 

Subscripts  will  be  from  a contiguous  range  T 


CORAL  66  allows  one  or  two  dimensional  arrays  each  element  of  which 
is  of  the  same  type.  It  requires  that  the  lower  ana  upper  bounds  be 
supplied  by  the  user  in  the  form  of  integers,  and  thus  be  determinable 
at  compile  time.  The  lanouage  definition  does  not  allow  the  computation 
for  the  upper  bound  to  be  deferred  until  scope  entry  time.  It  must  be 
available  at  compile  time. 

To  deter  processinq  of  upper  subscript  bound  implies  provision  for 
dynamic  array  sizes.  This  would  mean  that  storage  allocation  for  the 
array  would  be  done  at  the  run-time,  it  would  require  more  time  and 
care  to  execute  the  programs  having  dynamic  arrays.  Modifications  to 
the  translators  will  have  to  be  made  to  alter  the  existing 
syntax-checking  mechanism  (which  checks  for  the  numerical  value  of  both 
upper  and  lower  bounds),  the  storage  allocations  functions  (which 
allocate  core  for  arrays  at  compile  time),  and  the  compile  time 
di agnostics  . 


A7 . The  lanauage  will  permit  records  to  have  alternative 
structures,  each  of  which  is  fixed  at  compile  time.  The  name 
and  type  of  each  record  component  will  be  specified  by  the 
user  at  compile  time.  ....P 

Alternative  structures  for  records  are  possible  ................. T 

Discrimination  condition  may  be  any  Boolean  expression  F 
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The  OVERLAY  feature  of  CORAL  66  causes  apparently  different  data 
references  to  refer  simultaneously  to  the  same  objects  of  data  (i.e.,  as 
alternative  names  for  the  same  storage  locations.)  This  feature  can  be 
used  to  overlay,  and  later  access,  variables  and  array  or  record 
components.  However,  there  is  no  explicit  discrimination  condition 
available  to  the  user  for  accessinn  the  record. 

Tc  meet  this  requirement  tbe  language  will  have  to  provide  a 
mechanism  to  allow  the  user  to  evaluate  a boolean  expression  and  then 
use  one  or  the  other  form  of  record  in  his  program. 

Introduction  of  this  feature  will  require  changes  to  all  existing 
implementations  to  allow  the  OVERLAY  feature  to  work  in  conjunction  with 
the  discrimination  condition. 
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PI.  Assignment  and  reference  operation  will  be  automatically 
defined  for  all  data  types  which 'do  not  manage  their  dat-a 
storage.  The  assignment  operation  will  permit  any  value  of  a 
oiven  type  to  be  assigned  to  a variable,  array,  or  record 
component  of  that  type  or  of  a union  type  containinc  that 


type.  Reference  will  retrieve  the  last  assigned  value.  ....T 

Automatically  defined  for  any  type  (except...)  .....T 

Available  for  individual  components  T 

(Assignment  and  reference  via  functions)  F 


Assignment  to  integer,  floatinq  and  fixed  data  types  is  available 
in  CORAL  66,  as  is  the  user  ability  to  reference  the  values  stored. 
Components  of  arrays  and  records  can  also  be  individually  assigned  to  or 
referenced.  However,  the  assianirent  operation  is  not  defined  for  entire 
records  or  arrays,  even  if  they  are  conformable. 

No  conflicts  with  other  reauiremerts. 


B2 . The  source  lanauage  will  have  a built-in  operation  which 
can  be  used  to  compare  any  two  data  objects  (regardless  of 
type)  for  identity.  .T 


COPAL  66  contains  = operator  which  can  be  used  to  compare  two 
logically  equivalent  values  of  different  types  for  equivalence.  Thus  in 
a logical  comparison  floating  1.0  will  be  equal  to  integer  1. 

No  conflicts  with  other  requirements. 


B3.  Relational  operations  will  be  automatically  defined  for 


numeric  data  and  all  types  defined  by  enumeration.  ....P- 

Built-in  for  all  numeric  and  enumeration  types  P 

Ordering  can  be  inhibited  when  desired  .......................... F 


COPAL  66  provides  for  relational  operators  <,  <=,  :=,  >=,  <>  and  > 
for  looical  comparison  of  numeric  data.  However,  since  CORAL  66  does 
not  prrmit  status  variables,  automatic  ordering  of  enumerated  data  is 
not  permitted.  Hnordered  definitions  of  sets  is  also  not  allowed. 
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To  meet  this  requirement,  CORAL  66  will  have  to  define  STATUS 
variables  with  the  capability  to  define  their  associated  set  of  values 
either  in  an  ordered  or  unordered  way.  Introduction  of  this  tyoe  of 
variable  will  affect  the  existing  implementations  significantly.  All 
logical  expression  processina  will  have  to  be  modified.  Its  impact  on 
control  statements  will  require  changes  in  IF  and  F0R-WH1LE  statements 
also. 


All  existing  imr  lemerit  at  i ons  will  h^ve  to  be  modified  to  include 
the  Status  variables  and  changes  to  the  constructs  mentioned  in  the 
preceding  paragraph. 


P 4 . The  built-in  arithmetic  operations  will  include: 

addition,  subtraction,  multiplication,  division  (with  a real 
result),  exponentiation,  integer  division  (with  integer  or 
fixeo  point  arcuments  and  remainder),  and  reqation.  ....P* 

Addition  T 

Subtraction  .T 

Multiplication  ....T 

Division  with  real  result  T 

Exponentiation  .......F 

Integer  and  fixed  point  division  with  remainder  F 

Negation  ....................T 


CORAL  66  does  not  provide  for  exponentiation  nor  does  it  provide 
for  integer  division  with  remainder.  Inteoer  division  of  the  type 
K :=  I/J;  results  in  the  inteoer  quotient  being  stored  in  t and  the 
remainder  is  lost  to  the  user.  However  if  K were  defined  to  be 
floating,  then  I c-nd  J will  be  first  converted  to  floating  before 
division  takes  place.  The  function  INTFGER  has  to  be  used  in  such  cases 
to  force  division  before  conversion  (i.e.,  < :=  INTEGERCI/J);) . 
Operators  for  addition,  subtraction,  and  negation,  with  appropriate 
conversions  where  necessary,  are  also  provided.  . 

Implementation  of  exponentiation  can  be  done  via  software 
subroutines.  Many  CORAL  66  compilers  already  have  this  feature. 
Integer  division  with  remainder  will  require  some  syntax  changes  in  the 
language  to  enable  the  user  to  specify  where  the  remainder  has  to  be 
stored.  Poth  of  these  features  can  be  implemented  with  minimal  impact 
on  existing  translators.  Areas  impacted  will  be  syntax  analysis, 
expressions,  diagnostics  and  library. 
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B$.  Arithmetic  and  assignment  operations  on  data  which  are 
within  the  range  specifications  of  the  program  will  never 
truncate  the  most  significant  dioits  of  a numeric  quantity. 


Truncation  and  roundino 
significant  digits  and  will 
and  fixed  point  numbers, 
specified  precision  will 
numbers . 


will  always  be  on  the  least 
never  be  implicit  for  integers 
Implicit  rounding  beyond  the 
be  allowed  for  floating  point 


f 


Never  from  the  left  for  data  within  range  F 

Never  on  the  right  for  inteoer  and  fixed  point  F 

Implicit  floatinq  point  rounriina  beyond  precision  allowed  .......F 

(Run  time  checks  can  be  avoided)  N/A 


The  CORAL  66  language  does  not  provide  explicit  rules  or  functions 
for  truncation  from  the  right  for  integers  or  fixed  point  numbers  nor 
does  it  prohibit  truncation  from  the  left.  This  matter  is  left  entirely 
in  the  hands  of  the  implementors.  On  the  floating  point  numbers,  the 
user  has  no  option  to  specify  the  precision.  Fach  floating  number 
occupies  one  computer  word.  Their  level  of  precision,  and  the  precision 
of  intermediate  results  is  determined  by  the  hardware  or  the 
implementors.  Hence  the  language  fails  to  meet  this  requirement. 

The  CORAL  66  definition  can  he  modified  to  include  rules  for 
truncation  and  rounding.  Users  should  be  allowed  to  specify  precision 
for  floating  point  numbers.  Imp lementation  of  these  changes  can  be 
accomplished  with  minimal  effort.  It  is  conceivable  that  some  of  the 
existing  compilers  may  not  be  allowing  truncation  from  the  left.  Other 
features  impacted  as  a result  of  these  changes  will  be  multiplication, 
addition,  assianment,  and  expression  processing. 

The  existing  implementations  will  have  to  ensure  that  these  rules 
for  truncation  and  rounding  are  also  followed  to  compute  and  store  the 
intermediate  results. 


B6 . The  built-in  Boolean  operations  will  include  "and", 
"or",  "not",  and  "xor".  The  operations  "and"  and  "or"  on 


scalars  will  be  evaluated  in  short  circuit  mode.  ....P 

Short-circuit  and  ......T 

Short-circuit  or  T 

hot  F 

Xor  ..F 


CORAL  66  reouires  short  circuit  evaluation  of  the 
Boolean  operators.  It  does  not  provide  for  NOT  or  XOR. 


AND 


and 


OR 
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The  introduction  of  NOT  and  XOR  Boolean  operators  will  have  minimal 
impact  on  expression  evaluation  and  some  control  statements  requiring 
logical  conditions  (e.g.,  IF,  FOR-WHILf  etc.).  The  existing 
implementations  will  have  to  be  modified  accordingly. 


F»7.  The  source  language  will  cermit  scalar  operations  and 
assignment  on  conformable  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  loaical 


structure.  . . . . f 

Scalar  operations  on  arrays  ...F 

Assignment  between  records  and  arrays  of  conformable  type  F 


The  CORAL  66  language  definition  does  not  specify  that  scalar 
operations  be  extended  to  conformable  arrays  or  that  data  transfers  be 
permitted  between  records  or  arrays  of  identical  logical  structure. 
Some  implementations  of  CORAL  66  rrovide  some  of  these  facilities,  but 
that  is  an  accident  of  ' mplementation,  not  a language  specification. 

This  feature  is  not  difficult  to  implement.  It  would  require 
further  type  checking  for  arrays  and  components  of  records,  their 
conformal)  i li  ty  for  size  and  subscript  ranges  before  generating  cone  to 
perform  the  scalar  operations  cr  data  transfers  for  the  entire  array  or 
records . 


BP.  There  will  be  no  implicit  type  conversions  but  no 
conversion  operation  will  be  required  when  the  type  of  an 
actual  parameter  is  a constituent  of  a union  type  which  is 
the  formal  parameter.  The  lanouaoe  will  provide  explicit 
conversion  operations  among  integer,  fixed  point  and  floating 
point  data,  between  the  object  representation  of  numbers  ano 
their  reoresentations  as  characters,  and  between  fixed  point 


scale  factors.  . . - . P- 

so  implicit  conversions  F 

FarlTcit  between  inteqer,  fixed  point,  and  floating  point  T 

* an l ic  it  between  fixed  roint  scale  factors  F 

farlicit  between  integer  and  boolean)  F 

• ■ arlicit  hefv.  n inteqer  and  enumerated  types)  ..F 

•a-liflt  between  different  enumerated  types)  F 
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During  expression  processing  the  CORAL  66  language  definition 
permits  implicit  type  conversions.  However,  explicit  conversion 
operators  between  integer,  fixed,  or  floating  point  data  are  also 
available.  Any  expression  may  be  enclosed  in  parentheses  and  be 
explicitly  typed  by  a prefix  'INTEGER',  'FIXED'  scale,  or  'FLOATING'. 
For  example 

'FLOATING*  CN  ♦ • I NTF GE R ' ( X* Y - A/BI) 
is  a primary  of  tyoe  floating. 

To  introduce  and  further  emphasize  the  explicit  conversions  in  the 
language,  the  current  language  definition  and  implementations  will  have 
to  be  modified  to  forbid  implicit  conversion.  Some  modifications  to  the 
syntax-checking  procedures  will  also  have  to  be  made  to  accommodate 
explicit  conversions  between  two  fixed-point  scale  factors. 


B9.  Explicit  conversion  operations  will  not  be  required 
between  numerical  ranges.  There  will  be  a run  time  exception 


condition  when  any  integer  nr  fixed  point  value  is 
truncated.  ....P- 

Implicit  conversion  between  ranees  .............................. F 

Exception  condition  on  integer  and  fixed  point  truncation  P 


There  are  two  kinds  of  ranaes:  the  range  of  variables  and  the  range 
of  subscriots.  CORAL  66  does  not  permit  specification  of  ran ge  of 
variables,  hence  the  question  of  implicit  conversions  between  ranges 
does  not  arise  in  this  case.  Array  size  ranges  are  required  in  CORAL 
66,  tut  they  must  be  supplied  by  the  user  as  integer  constants  and  are 
compile  time  evaluable.  The  definition  seems  to  imply  that  an  srror 
message  will  be  issued  tn  the  user  if  he  supplies  other  than  an  integer 
constant  as  a subscript  range.  No  automatic  conversion  is  implied. 

The  language  does  not  require  that  an  exception  condition  be  raised 
if  an  integer  or  fixed  point  number  is  truncated. 

The  language  does,  however,  permit  a run-time  mode  of  operation  in 
which  exception  conditions  are  raised  if  the  subscriot  range  is 
exceeded. 

To  meet  this  requirement  CORAL  66  compilers  may  have  to  be  modified 
to  allow  subscript  ranges  of  types  other  than  integers,  and  also  to 
permit  automatic  conversions  or  truncation  of  these  ranges  to  integers. 
The  concept  of  ranqes  for  all  variables  will  have  to  be  introduced  and 
the  language  syntax  modified  to  accomplish  this. 
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BIO.  The  base  lanquaqe  will  provide  operations  allowing 
proorams  to  interact  with  files,  channels,  or  devices, 
including  terminals.  These  operations  will  permit  sendim 
and  receiving  both  data  and  control  information,  will  enable 
programs  to  dynamically  assign  and  reassign  I/O  devices,  will 
orovide  user  control  for  exception  conditions,  and  will  not 


be  installation  dependent.  ....F 

Sending  and  receivinq  of  data  f 

Sending  and  receiving  of  control  information  .F 

Dynamic  device  assignment  F 

User  exceotion  condition  control  F 

Installation  independence  ...f 

(Data  f or matt i na  capability)  .................................... F 

(Reading  and  writing  of  bit  strings)  ............................  F 


The  CORAL  66  lanquaoe  makes  no  provision  for  I/O  statements  as  part 
of  the  official  language  definition. 

Lanouaoe  features  to  select  a device,  open  and  close  a *ilt,  read 
and  write  data,  handle  interrupts,  etc.  should  be  defined.  An  I/O 
package,  similar  to  the  one  currently  available  on  the  6EA080  computer 
at  the  Royal  Radar  Establishment,  should  be  used  (with  necessary 
modifications)  to  carry  out  the  functions  required  by  the  I/O 
statements . 


B 1 1 . The  language  will  provide  operations  on  data  types 
defined  as  cower  sets  of  enumeration  types  (see  F6)  . These 
operations  will  include  union,  intersection,  difference. 


complement,  and  an  element  predicate. 

Un  ion ...T 

Intersection  ......T 

Difference  T 

Como  lement  F 

Membership  predicate  ....F 

(Set  inclusion)  F 


CORAL  66  permits  the  operations  of  DIFFER,  UNION  and  mask  to 
perform  the  logical  operations  of  difference,  union  and  intersection 
respectively.  It  does  not  provide  for  other  logical  operations 
specified  in  Tinman  requirements.  These  operations  are  only  defined  for 
the  existina  types  since  CORAL  66  does  not  allow  user-defined  data 
types . 
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To  fully  meet  this  requirement  the  language  will  have  to  (1)  allow 
user  definition  of  new  data  types  and  (2)  allow  all  of  the  powerset 
operations  specified  above  to  be  applicable  to  both  the  built-in  data 
'types  as  well  as  the  user  defined  data  types.  This  would  require  major 
changes  to  the  current  definition  of  the  lanquage  as  well  as  to  the 
existino  implementations. 


V 
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Cl  . Side  effects  which  are  dependent  on  the  evaluation  order 
among  the  arauments  of  an  expression  will  be  evaluated 
let t-to-right- 


Side  effects  must  occur  in  let t-to-right  order  P- 

(Embedded  assignments)  ..F 


CORAL  66  definition  does  not  soecify  algorithms  for  expression 
evaluation  and  leaves  their  imr l ement at  ion  dependent.  Only  for 
evaluation  of  library  built-in  functions  in  a simple  expression  does  the 
language  definition  state  that  they  will  be  evaluated  in  the  order  in 
which  they  appear  when  the  expression  is  read  from  left  to  right, 
regardless  of  brackets.  The  only  exception  to  this  rule  is  when  other 
functions  appear  as  value  parameters  of  a function  and  hence  must  be 
evaluated  before  the  function  is  evaluated  (i.e.,  the  order  of 
evaluation  of  s i n ( crs (exp (n) ) ) will  be  exo,  cos,  sin.). 

To  establisn  uniformity  in  all  implementations,  the  language 
definition  should  specify  rules  for  expression  evaluation.  Only  where 
the  order  of  evaluation  is  important  should  the  language  impose  the 
restriction  that  evaluation  must  proceed  from  left  to  rioht.  In  other 
instances  the  compiler  implementors  should  be  given  the  choice  in 
selectino  evaluation  rules,  as  long  as  the  effect  and  the  results  of 
evaluation  are  not  changed. 

Such  a change  is  likely  to  affect  the  existing  implementations 
which  have  followed  their  own  rules  for  the  order  of  evaluating 
expressions . 


C ?.  Which  parts  of  an  expression  constitute  the  operands  to 
each  operation  within  that  expression  should  be  obvious  to 
the  reader.  There  will  be  few  levels  of  operator  hierarchy 


and  they  will  he  widely  recognized.  ....P 

Few  precedence  levels  F 

No  user-definec  precedence  levels  ...............................  I 

Operands  of  an  operation  are  obvious  ............................ T 


CORAL  66  does  not  detine  precedence  levels  for  the  operators.  The 
only  established  rrecedence  rule  is  that  all  syntactically  outermost 
terms  in  an  expression  will  be  evaluated  to  the  required  numeric  type 
before  the  adding  operators  are  applied.  If  an  expression  is  enclosed 
in  parentheses,  its  terms  are  not  outermost  and  the  rule  no  longer 
applies.  The  algorithm  for  the  particular  compiler  will  determine  the 
sequence  of  events. 
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A few  precedence  rules  for  operator  hierarchy  can  be  established  in 
the  language  definition.  This  may  affect  some,  though  not  all, 
imp lementations . For  instance,  one  set  of  precedence  rules  can  be: 
•m»SK',  'UNION*,  'DIFFER',  */,  +-,  and  the  ordinary  oriority  of 
operators  may  be  changed  by  usino  parentheses  within  an  expression. 


C3.  Expressions  of  a given  type  will  be  permitted  anywhere 
in  source  programs  where  both  constants  and  references  to 
variables  of  that  type  are  allowed.  ....T 


The  language  allows  expressions  wherever  both  constants  and 
variables  are  allowed. 


No  conflicts  with  other  requirements. 


C4.  Constant  expressions  will  be  allowed  in  programs 
anywhere  constants  are  allowed,  and  constant  expressions  will 
be  evaluated  before  run  time.  ....F 


The  official  definition  of  CORAL  66  does  not  permit  constant 
expressions  wherever  constants  are  allowed.  For  instance, 
F I XED (2*?, 3/1 ) X , Y ; is  an  illegal  data  definition,  whereas  FIXED(16,3) 
X,Y;  is  acceptable.  Similarly,  the  lower  and  upper  bounds  of  the  array 
in  an  array  declaration  must  be  a constant,  and  not  a constant 
expression. 

If  a requirement  is  established  in  the  language  definition  that  all 
constant  expressions  must  be  evaluated  before  run  time,  then  CORAL  66 
will  meet  this  requirement.  Constant  expressions,  such  as  in  the 
examples  above,  can  then  be  legally  used.  This  will  require  minimal 
changes  to  syntax  checking  routines  of  existing  compilers. 


C5.  There  will  be  a consistent  set  of  rules  applicable  to 
all  Darameters,  whether  they  be  for  procedures,  for  types, 
for  exception  handlinq,  for  parallel  processes,  for 
declarations,  or  for  built-in  operators.  There  will  be  no 
special  operations  (e.a.,  array  substructuring)  applicable 
only  to  parameters.  Uniformity  and  consistency  contribute  to 
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ease  of  learninn.  ....P 

Parameter  rules  consistent  in  all  contexts ...F 

No  special  operations  applicable  only  to  parameters  .............1 


CORAL  06  allows  procedure  parameters,  parameters  for  declarations, 
and  built-in  operators,  but  ones  not  permit  parameters  for  exception 
handling  or  parallel  processing.  while  procedure  parameters  can  be 
objects  of  data,  rlaces  in  the  program,  data  references,  procedure 
names,  expressions,  etc.,  the  parameters  in  several  data  declarations 
(e.g.,  FIXED  option)  can  only  be  inteqer  constants.  Hence  the  language 
is  not  uniform  in  its  treatment  of  parameters  in  the  sense  of  the  Tinman 
requirements.  However,  no  special  operations  are  allowed  on  parameters 
which  are  also  not  permitted  for  ether  structures. 

The  lancuare  will  have  to  provide  for  exception  handling  control 
(or  other)  features,  for  parallel  processing  and  for  user  definition  of 
new  operators.  These  are  all  major  changes  to  the  existing  language  and 
will  require  significant  effort  to  ‘implement . 


C6.  Format  and  actual  parameters  will  always  agree  in  type. 
The  number  of  dimensions  for  array  parameters  will  be 
determinable  at  compile  time.  The  size  and  subscript  rarge 
for  array  parameters  need  not  be  determinable  at  compile 
time,  but  can  be  passed  as  rart  of  the  parameter. 


Actual  and  formal  parameters  will  aor^e  in  type  .........T 

Rank  of  parameter  arrays  is  fixed  at  compile  time  ............... T 

Parameter  array  size  and  subscript  range  can  be  passed  F 


CORAL  66  requires  type  checkinq  for  compatibility  between  actual 
and  formal  parameters.  It  also  reauires  that  the  number  of  dimensions, 
the  size,  and  the  subscript  range  for  array  parameters  be  known  at 
compile  time.  Thus  it  does  not  allow  for  dynamic  arrays  and  hence  does 
not  meet  part  of  this  requirement. 

The  lanauaqe  definition  must  be  modified  to  allow  for  dynamic 
arrays  and  also  passing  of  parameters  related  to  the  size  and  subscript 
ranges  of  these  arrays.  This  would  he  a significant  change  for  existing 
implementations . 


C 7 


There  will  be  only  four  classes  of  formal  parameters 
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For  data  there  will  be  those  which  act  as  constants 
representing  the  actual  parameter  value  at  the  time  of  call, 
and  those  which  rename  the  actual  parameter  which  must  be  a 
variable.  In  addition,  there  will  be  a formal  parameter 
class  for  specifying  the  control  action  when  exception 


conditions  occur  and  a class  for  procedure  parameters.  ....P+ 

Act  as  constants  (call  by  value  plus)  T 

Act  as  variables  (call  by  reference)  T 

Fxception  control  F 

Procedure  oarameters  T 

(Act  as  variables,  but  call  by  value)  T 

(Act  as  variables,  result  parameter)  T 


CORAL  66  provides  for  all  of  these  types  of  parameters  with  the 
excepti  on  of  exception  handling  parameters.  There  is  no  prevision  for 
exception  handlinct  in  the  languaoe.  However,  it  also  provides  for 
parameters  not  required  by  the  Tinman  requirements  (e.q.,  SWITCH). 

The  exception  handling  mechanisms  should  be  added  to  language 
features  (e.o.,  ON  OVERFLOW  etc.)  which  allow  transfer  of  control  to 
labels  outside  the  scope  in  which  the  exception  condition  occurs.  Those 
types  of  parameters  (e.g.,  SWITCH)  which  are  not  required  by  thp  Tinman 
requirements  should  be  disallowed. 


C8.  Specification  of  the  type,  range;)  precision,  dimension, 
scale,  and  format  of  parameters  will  be  optional  in  the 
procedure  declaration.  None  of  them  will  be  alterable  at  run 


time.  • • . . 

Above  properties  optional  ..F 

Above  properties  are  fixed  at  run  time  .....P 


CORAL  66  does  not  support  the  capability  to  define  generic 
procedures  in  which  the  type  of  the  parameters  is  determined  at  compile 
time  by  the  type  of  the  actual  parameters.  The  type  specification  tor 
each  parameter  cn  the  formal  side  is  required  in  CORAL  66  and  is  not 
optional  as  specified  by  the  Tinman  requirements.  The  same  is  true  for 
dimensions  of  the  arrays  and  scale  factors  of  fixed  point  variables. 
CORAL  66  does  not  permit  specification  of  range,  precision,  or  format  in 
parameters. 

Implementation  of  this  requirement  will  imply  many  changes  in  the 
existing  calling  mechanism  of  the  lanquage.  Each  parameter,  for 
instance,  will  be  followed  by  type  specification,  a range  of  values, 
precision  specification  where  applicable,  dimensions,  and  scale  in  the 
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calling  mechanism.  Some  of  these  items  are  not  even  currently  defined 
in  the  language.  Additionally  checking  for  these  items  will  have  to  oe 
implemented  on  both  the  actual  a?  well  as  the  formal  side  of  the  call. 
On  the  formal  side  the  generic  rrocedure  capabilities  will  have  to  oe 
introduced  which  will  require  selection  and/or  generation  of  code  for 
the  formal  procedure  for  the  type,  mode,  precision,  etc.  required  by  the 
actua  l calls. 


C9.  There  will  be  provision  for  variable  numbers  of 
arguments,  but  in  such  cases  all  but  a constant  number  o* 
them  must  be  of  the  same  type.  Whether  a routine  can  have  a 
variable  number  of  arquments  must  be  determinable  from  its 
description  and  the  number  of  arguments  for  any  call  will  be 


determinable  at  compile  time.  ....F 

Variable  number  of  arquments  rossitle  ......F 

»ll  but  a constant  number  of  arquments  have  the  same  type  .......F 

Number  of  arguments  in  each  call  is  fixed  at  compile  time  -F 


This  facility  is  not  available  in  CORAL  66. 

Imr lementation  of  this  capability  will  affect  the  lanquage  and  all 
implementations.  It  will  require  provision  for  variable  number  of 
parameters  in  procedure  calls.  Even  the  existing  I/O  procedures  in  some 
of  the  existing  implementations  will  have  to  be  modified  to  accommodate 
this  . 
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01.  The  user  will  have  the  ability  to  associate  constant 
values  of  any  type  with  identifiers.  ...,f 


CORAL  66  does  not  permit  an  identifier  to  be  associated  with  a 
constant,  except  by  assignment. 

Minimal  changes  to  the  language  definition  and  existing 
implementations  will  he  required  to  allow  a variable  tc  be  declared  a 
constant  and  be  associated  with  the  value  of  a constant  of  the  same 
type  . 


D2.  The  language  will  provide  a syntax  and  a consistent 
interpretation  for  constants  of  built-in  data  types.  Numeric 
constants  will  have  the  same  value  (within  the  specified 


precision)  in  both  programs  and  data  (input  or  output).  ....P 

Literals  for  all  built-in  types  T 

Consistent  interpretation  in  program  and  data  ......F 


The  CORAL  66  definition  provides  for  the  syntax  for  the  built-in 
data  types  e.g.,  fixed,  floating  and  integer.  Blandford  extensions  to 
the  language  also  include  definition  and  syntax  tor  characters.  But  the 
language  does  not  provide  for  I/O  features  nor  does  it  specify  the 
syntax  for  data  to  be  input  or  output. 

Several  implementations  (maybe  all  existinq  implementations)  of 
CORAL  66  allow  the  same  value  for  numeric  constants  within  the  program 
and  I/O  data.  To  meet  this  requirement,  standardized  I/O  features  have 
to  be  included  in  the  language  definition.  Minimal  changes  to  process 
those  I/O  statements  utilizing  existing  I/O  routines  and  facilities  will 
be  required  in  the  existing  implementations. 


D3.  The  lanquaae  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  part  of  their  declaration. 
Such  variables  will  be  initialized  at  the  time  of  their 
apparent  alloration  (i.e.,  at  entry  to  allocation  scope). 


There  will  be  no  default  initial  values.  ....d* 

Initial  value  can  be  specified  as  part  of  the  declaration  T 

Initialization  occurs  at  allocation  scope  entry  T 

No  aefault  initial  values  .........f 
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CORAL  66  allows  initialization  of  variables  at  the  time  of  their 
declaration.  Initialization  of  these  variables  tmkes  place  at  th<»  time 
of  scope  entry.  However,  there  is  no  lanquage  specified  guarantee  that 
no  default  initial  values  will  be  assicned  to  variables  not  explicitly 
initialized  by  the  user.  Nor  dees  the  language  definition  specify  that 
an  error  condition  will  be  raised  if  a uninitialized  variable  is 
accessed  before  assignment  of  a value.  The  subject  is  implementation 
dependent.  Hence  CORAL  66  does  rot  meet  this  portion  of  the 
reoui rement . 

All  existing  implementations  will  be  affected  if  they  are  to  meet 
this  requirement.  It  will  reouire  provisions  for  compile  time  checks  to 
ensure  that  no  variable  is  being  accessed  without  first  beino  given  a 
value  either  by  assignment,  1/0,  or  initialization.  Frror  diagnostics 
should  he  given  if  this  is  not  the  case.  Furthermore,  no  implementation 
should  initialize  variables  by  default,  as  is  commonly  done. 


D4.  The  source  lannuage  will  require  its  users  to  specify 
individually  the  ranqe  of  all  numeric  variables  and  the  step 
size  for  fixed  point  variables.  The  range  specifications 
will  be  interpreted  as  the  maximal  range  of  values  which  will 
be  assigned  to  a variable  and  the  minimal  range  which  must  be 
supported  by  the  object  code.  Range  and  step  size 
specifications  will  not  be  interpreted  as  defining  new 


types.  . . . . F 

Numeric  variable  range  specification  mandatory  ..........F 

Fixed  point  variable  step  size  specification  mandatory  F 

Range  and  step  size  specifications  do  not  define  a new  type  N/A 


COPAL  66  does  not  allow  range  specifications  for  numeric  variables 
nor  does  it  permit  step  size  specification  for  fixed  point  variables. 

Implementation  of  this  feature  will  require  modification  of  CORAL 
66  syntax  to  allow  explicit  range  specification  for  all  variables  and 
step  size  specification  for  fixed  point  variables.  The  compilers  will 
then  have  to  generate  code  to  check  tor  ranges  at  execution  time. 


D5.  The  range  of  values  which  can  be  associated  with  a 
variable,  array,  or  record  component,  will  be  any  built-in 
type,  any  defined  tyre,  or  a contiguous  subsequence  of  any 
enumeration  type.  ....d 
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Ranges  of  an  enumeration  type  are  allowed  F 

No  arbitrary  restrictions  on  the  structure  of  data  P- 


CORAL  66  does  not  meet  the  first  part  of  this  reouirement  because 
it  does  not  permit  specification  of  any  kind  of  ranges. 

In  the  second  part  of  the  requirement,  there  is  no  way  that  records 
can  he  made  part  of  an  array  nor  is  it  conveniently  possible  to  make 
arrays  - part  of  a record.  However,  in  table  declarations  (which 
represent  records)  ore  can  define  an  element  of  an  array  as  constituting 
one  entry  in  the  record.  Subsenuent  entries  in  the  table  can  be  made  to 
represent  subsequent  elements  of  the  array.  Only  in  this  partial  sense 
can  an  array  be  made  a component  of  a record. 

To  completely  meet  this  requirement  would  require  changes  in  the 
language  and  the  imo lementat ions . The  language  has  to  be  modified  to 
accept  ranges  in  declarations,  definition  of  new  data  types,  status 
variables,  and  an  expanded  definition  of  records  and  arrays,  to  permit 
the  inclusion  of  arrays  in  record  definition  and  vice  versa. 


C6.  The  language  will  provide  a pointer  mechanism  which  can 
be  used  to  build  data  with  shared  and/or  recursive 
substructure.  The  pointer  property  will  only  affect  the  use 
of  variables  (including  array  and  record  components)  of  some 
data  types.  Pointer  variables  will  be  as  safe  in  their  use 


as  are  any  other  variables.  ....P- 

Recursive  and  network  structures  provided  ...................... .F 

Handles  variable-value  and  structure-component  connections  P 

Pointer  property  is  an  attribute  of  a typed  variable  F 

Pointer  property  not  for  constants,  affects  only  assignment  I 

Pointer  property  mandatory  for  dynamic  allocation  F 

Allocation  scooe  never  wider  than  access  scope  .T 

(Either  the  value  or  the  pointer  is  modifiable)  T 

(Pointer  mechanism  handles  procedures  and  parameters)  ...........P 

(Remap  and  replace  assignment  have  different  syntaxes)  F 

(Built-in  dynamic  variable  creation)  .F 

(Variable  equivalence  classes  are  declarable)  F 


CORAL  66  does  not  provide  for  a pointer  data  type.  However,  its 
LOCATION  operator  can  be  used  to  point  to  the  location  containing  data 
values  for  a variable  or  array  and  to  access  those  values.  The  lanquage 
does  not  provide  any  safety  features  for  this  option  and  the  programmer 
himself  has  to  ensure  the  validity  of  the  pointers  and  the  data  being 
accessed.  If  the  pointer  is  pointing  to  the  first  item  in  a table  or 
array,  items  in  the  subsequent  words  can  be  referenced;  but  if  the  item 
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is  located 
referenced. 

in 

a part  of  a 

word,  there  is 

no  guarantee 

that 

it  can  be 

a Ithough 

it 

is  possible 

to  structure 

lists  using 

the 

LOCATION 

option,  the  CORAL  66  language  does  not  permit  declaration  of  such  lists 
in  the  data  definition.  The  LOCATION  option  is  also  inadeouate  to 
define  recursive  data  structures. 

To  properly  meet  this  requirement,  the  language  must  provide  for  a 
pointer  ;ata  type  capable  of  pointing  at  variables,  arrays,  tables, 
elements  of  tables,  procedures,  parameters  etc.,  and  to  allow  recursive 
data  definitions  and  null  references.  It  must  allow  tor  easy 
modification  of  the  data  value  pointed  to  or  the  pointer  value  itself. 
Such  changes  in  the  language  will  affect  all  existina  implementations. 
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El.  The  user  of  the  language  will  be  able  to  define  new  data 
types  and  operations  within  programs.  ....F 


CORAL  66  does  not  provide  for  user  definition  of  new  data  types  or 
operations. 

Special  type  checkinq  mechanisms  will  have  to  be  added  to  existinq 
comoilers  to  allow  for  recoonition  of  new  data  types  and  operations  and 
then  their  use  as  built-in  tyres.  The  languaae  definition  will  have  to 
be  modified  to  show  how  new  data  types  and  operators  can  be  adoed  and 
used  . 


E 2.  The  "use"  of  defined  types  will  be  indistinguishable 
from  built-in  types.  ....F 


Not  applicable  to  COPAL  66  since  it  does  not  allow  defined  types. 

The  changes  needed  to  fulfill  this  requirement  are  discussed  under 
requi rement  FI . 


E3.  Each  program  component  will  be  defined  in  the  base 
lanouage,  in  a library,  or  in  the  program.  There  will  be  no 
default  declarations.  ...,r 


CORAL  66  requires  that  every  data  item  be  explicitly  declared 
before  use. 

No  conflict  with  other  requirements. 


F4.  The  user  will  be  able,  within  the  source  longuaqe,  to 
extend  existinq  operators  to  new  data  types. 


F 


CORAL  66  does  not  allow  defined  data  types  and  hence  does  not 
provide  the  capability  of  extending  the  existing  operators  to  oefined 
types  . 
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In  addition  to  definitional  facilities  specified  in  El,  a mechanism 
should  also  be  provided  to  specify  the  operations  that  can  be  performed 
on  the  defined  data  types.  Other  language  features  will  also  be 
affected  since  their  definition  will  have  to  be  extended  to  provide  for 
new  data  types  and  new  operators. 

All  of  these  modifications  specified  in  El  and  in  the  precedinq 
paranraph  will  significantly  impact  all  existing  implementations. 


E5.  Type  definitions  in  the  source  language  will  permit 
definition  of  both  the  class  of  data  objects  comprisinc  the 
type  and  the  set  of  operations  applicable  to  that  class.  A 
defined  type  will  not  automatically  inherit  the  operations  of 


the  data  with  which  it  is  represented.  ....F 

Construction  ..............................F 

Selection  .....F 

Predicates  ..................................................  ....F 

Tyre  conversions  F 

Operations  and  data  can  be  defined  together  .....................  F 


COPAL  66  does  not  allow  definition  of  new  operations  or  data  types, 
hence  dees  not  meet  this  requirement. 

Thf  entire  capability  to  extend  the  capabilities  of  the  lanquage  to 
meet  the  needs  of  different  applications  by  allowing  user  to  define  new 
data  types  and  new  operations  has  to  be  added  to  the  languaqe. 
Furthermore,  the  user  should  be  able  to  associate  new  operations  with 
new  data  types  and  should  also  be  permitted  to  extend  existinq 
operations  to  new  data  types.  This  would  require  changes  in  existing 
translators  in  the  area  of  lexical  and  syntax  analyzer,  construction  of 
dictionaries  and  intermediate  language  table,  and  the  type  checkino 
mechanisms. 


E6.  The  data  objects  comprisino  a defined  type  will  be 
definable  by  enumeration  of  their  literal  names,  as  Cartesian 
products  of  existino  types  (i.e.,  as  array  and  record 
classes),  by  discriminated  union  (i.e.,  as  the  union  of 
disjoint  types)  and  as  the  power  set  of  an  enumeration  tyoe. 
These  definitions  will  be  orocessed  entirely  at  compile 


1 1 me . . . . . F 

Enumeration ...........F 
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Cartesian  products  (records)  ...... F 

Discriminated  union  F 

Powerset  of  an  enumeration  type  F 


CORAL  66  does  not  support  defined  types  at  all. 

The  changes  needed  to  fulfill  this  requirement  are  discussed  under 
requirement  El. 


E7.  Type  definitions  by  free  union  (i.e.,  union  of 
non-disjoint  types)  and  subsetting  are  not  desired.  ....F 

CORAL  66  has  an  overlay  capability,  which  provides  a form  of  free 
union . 

To  remove  the  overlay  capability  would  greatly  simplify  existinq 
compilers,  but  would  have  a profound  effect  on  existing  programs  writtpn 
in  CORAL  66. 


E8.  When  defining  a type,  the  user  will  he  able  to  specify 
the  initialization  and  finalization  procedures  for  the  type 
and  the  actions  to  be  taken  at  the  time  of  allocation  and 


deallocation  of  variables  of  that  type.  ...,F 

Initialization  F 

Finalization  f 

Allocation  actions  F 

Deallocation  actions  F 


Since  the  language  does  not  allow  definition  of  new  types,  the 
questions  of  initialization,  allocation,  etc.  of  new  data  types  does  not 
arise. 

The  changes  needed  to  fulfill  this  requirement  are  discussed  under 
requirement  F5. 
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FI.  The  languaoe  Kilt  allow  the  user  to  distinguish  between 
scope  of  allocation  and  scope  of  access.  ....T 


CORAL  66  allows  allocation  of  storage  for  variables  at  the 
beginning  of  procedures,  in  a block  (e.p.,  between  BEGIN  and  END 
statements)  and  via  a COMMON  statement.  Access  to  the  variables  is 
controlled  by  language  defined  rules.  A variable  allocated  by  a COMMON 
statement  can  be  accessed  by  several  procedures  having  that  variable  in 
their  COMMON  dec larations;  a variable  declared  at  the  beginning  of  a 
procedure  can  be  accessed  from  anywhere  within  the  procedure  except  in 
embedded  macros  or  blocks  containing  another  declaration  with  the  same 
name.  A variable  declared  within  a BEGIN  and  END  block  will  only  be 
accessible  within  that  block.  Thus  CORAL  66  fully  reets  this 
reauirement  because  it  separates  the  scopes  of  allocation  and  access  for 
defined  data. 

No  conflicts  with  other  requirements. 


F 2 . The  ability  to  limit  the  access  to  separately  defined 
structures  will  be  available  both  where  the  structure  is 
defined  and  where  it  is  used.  It  will  be  possible  to 
associate  new  local  names  with  separately  defined  program 


components.  ....h- 

A l low-able  operations  can  be  limited  F 

Access  can  be  limited  where  used  F 

External  declarations  need  not  all  have  the  same  scope  T 

Naming  conflicts  can  be  avoided  (renaming)  F 


CORAL  66  does  not  allow  specification  of  access  rules  during  the 
definition  of  structures  (procedures,  data  etc.),  nor  does  it  allow 
specification  of  access  rules  at  the  place  where  the  structure  is  used. 
At  the  time  of  structure  usage  lanouage-def ined  access  rules  are 
followed  in  case  of  a conflict  of  names,  but  the  user  has  no  choice  in 
the  matter. 

CORAL  66  also  does  not  have  a renaming  facility  for  cases  where  two 
or  more  names  refer  to  same  location. 

However,  the  current  definition  of  CORAL  66  permits  different 
scopes  for  items  declared  in  COMMON  statement.  This  is  done  at  the  time 
of  variable  definition. 

The  ability  to  limit  access  to  structures  both  where  they  are 
defined  and  where  they  are  accessed  will  require  extensive  changes  in 
language  syntax  and  implementations.  A mechanism  will  have  to  be 
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specified  to  state  the  scope  and  access  rules  at  the  time  of  structure 
definition.  implementations  will  have  to  he  modified  to  test  lor  access 
rights  each  time  a structure  tries  to  access  another  structure. 


F3.  The  scope  of  identifiers  will  be  wholly  determined  at 
compile  time.  ,...T 


This  is  required  in  CORAL  66  definition.  Scope  rules  have  been 
specified  and  resolution  of  apparent  conflicts  in  names  is  resolved 
before  code  generation  time. 

No  conflicts  with  other  requi rements . 


FA.  A variety  of  application-oriented  data  and  operations 
will  be  available  in  libraries  and  easily  accessible  in  the 
language.  . . . . T 


The  capabilities  to  develop  application  oriented  libraries  are 
available  in  the  lanquaqe.  The  LIBRARY  option  permits  the  use  of 
procedures  stored  in  the  library. 

No  conflict  with  other  requirements . 


F 5 . Program  components  not  defined  within  the  current 
program  and  not  in  the  base  language  will  be  maintained  in 
compile  time  accessible  libraries.  The  libraries  will  be 
capable  of  holdina  anything  definable  in  the  language  and 
will  not  exclude  routines  whose  bodies  are  written  in  other 


source  languages.  ....P 

Program  component  libraries  accessible  at  compile  time  P 

Libraries  can  contain  foreign  lanouage  routines  T 

Interface  requirements  checkable  at  compile  time  ...F 


The  libraries  of  CORAL  66  are  not  capable  of  holding  anything 
definable  in  the  lanquaqe.  For  example,  it  cannot  hold  data  definitions 
hy  themselves  unless  they  are  parts  of  a procedure.  The  use  of  EXTERNAL 
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option  allows  interfaces  with  object  programs  compiled  from  other  source 
codes  provided  they  are  compatible  with  the  loader.  Thus  the  check  for 
compatibility  with  these  routines  is  made  at  load  time  ano  not  at 
compile  time. 

Kodi f i cat  ions  to  the  language  to  define  and  store  groups  ot  data 
definitions  in  the  library  for  later  access  by  procedures  is  necessary 
to  meet  this  requirement.  This  facility  will  have  to  be  included  in 
•xistinn  implementations.  Furthermore,  the  existing  implementations 
will  have  to  be  modified  to  allow  comp i l t time  checks  with  object  code 
comDiled  from  other  source  codes  instead  of  at  the  load  time,  as  is 
specified  in  the  CORAL  66  definition. 


F 6 . Libraries  and  Compools  will  be  indistinguishable.  Thev 
will  be  capable  of  holdino  anything  definable  in  the 
lanuuaoe,  and  it  will  he  fossifcle  to  associate  them  with  any 
level  of  programming  activity  from  systems  through  projects 
to  individual  proorams.  There  will  he  many  specialized 
compools  or  libraries  any  user  specified  subset  of  which  is 
immediately  accessible  from  a given  program. 

Libraries  and  compools  will  be  indistinguishable  ..I 

Immediately  accessible  sublibraries  at  any  level  ................  r1 


CORAL  66  does  not  provide  for  comnools.  It  does  not  allow  for 
partitioning  of  libraries  accordinn  to  use  by  different  projects 
although  the  effect  can  be  achieved  by  the  existing  lihrary  facilities 
which  allow  any  number  of  project  oriented  routines  to  be  compiled  and 
stored  tor  later  access  by  project  programs. 

The  implementations  will  have  to  be  modified  to  include  the  compool 
facilities  and  to  make  them  compatible  with  the  existing  library 
facilities.  Simple  procedures  must  also  be  developed  for  partitioning 
libraries  according  to  general  or  specialized  use. 


F7.  The  source  language  will  contain  standard  machine 
independent  interfaces  to  machine  dependent  capabilities, 
including  peripheral  equipment  and  special  hardware.  ....F 


CORAL  *6  does  not  provide  for  standard  machine  independent 
capabilities  for  I/O,-  file  management,  or  other  peripheral  usage.  No 
attempt  has  been  made  to  standardize  lannuaqe  interface  with  the 
operating  system. 


CORAL  <*>6 
Requirement  F7 


This  is  a difficult  feature  to  define.  Standardization  of  language 
interface  with  the  OS  is  still  beyond  the  state-of-the-art.  However, 
some  language  features  can  be  defined  to  perform  I/O  functions.  Changes 
will  be  required  in  the  existing  implementations  to  accommodate  this. 
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61.  The  language  will  provide  structured  control  mechanisms 
for  sequential,  conditional,  iterative,  and  recursive 
control.  It  will  also  provide  control  structures  for 

(pseudo)  parallel  processing  exception  handling,  and 

asynchronous  interrupt  handling.  ....P 

Secuential  execution  T 

Conoitional  execution  T 

Iteration  T 

Recursion  ..........P 

(Pseudo)  parallel  processino  F 

Exception  handling  . . . F 

Asynchronous  interrupt  handlino  F 

Control  structures  from  a small  set  cf  simple  primitives  ........T 


CORAL  66  permits  the  normal  seouential  execution  of  statements, 
provides  for  IF-THFN-FLSF.  conditional  control  and  FOP  loop  for  iteration 
control.  It  optionally  allows  the  RFCHRS1VE  option  to  be  specified  for 
procedures.  However,  it  does  not  provide  for  pseudo  or  real  parallel 
processinq,  exception  handlino,  or  interrupt  handling.  The  language  has 
defined  a small  set  of  primitives  which  have  been  used  to  build  these 
control  structures. 

The  lanquaqe  needs  to  define  control  structures  which  allow  the 
user  to  perform  parallel  processing,  exception  handling,  and  interrupt 
handling.  These  features  will  have  a significant  inract  on  all  “xisting 
implementations. 


G2 . The  source  language  will  provide  a “60  TO”  operation 
applicable  to  program  labels  within  its  most  local  scope  of 
definition.  ....F 


COPAL  66  allows  labels  to  be  defined  in  the  COMMON  statement  and 
tbus  feririts  global  jumps  from  one  segment  to  another.  Hence  it  does 
not  meet  this  requirement. 

No  conflict  with  other  requirements . 


63.  The  conditional  control  structures  will  be  fully 
oartitioned  and  will  permit  selection  among  alternative 
computations  based  on  the  value  of  a Boolean  expression,  on 
the  subtype  of  a value  from,  a discriminated  union,  or  on  a 
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computed  choice  amono  labeled  alternatives.  ....P* 

Baser!  cn  Boolean  expression  T 

Based  on  type  from  discriminated  union  .......................... F 

Rased  on  computed  choice  among  labeled  alternatives  ............. T 

All  alternative  must  be  accounted  for  T 

Simple  mechanisms  will  be  supplied  fer  common  cases  ............. P 


CORAL  66  allows  Boolean  expressions  in  its  IF-THEN-ELSE  control 
structure.  The  result  of  evaluation  of  Poolean  expression  in  short 
circuit  mode  determines  thp  action  to  be  taken.  The  language  also 
allows  a SWITCH  statement  in  which  the  control  is  transferred  to  one  of 
the  labelled  variables  depending  upon  the  value  of  the  index  hut  not  the 
type  of  the  discriminated  union.  The  language  requires  all  alternatives 
in  the  conditional  controls  properlv  accnunteo  for.  It  also  permits 
simple  mechanisms  for  common  cases  by  allowing,  for  example,  a short 
circuit  mode  evaluation  of  Boolean  conditions  in  IF  statement. 

No  conflicts  with  other  reaui r ements . 


G4.  The  iterative  control  structure  will  oermit  the 
termination  condition  to  appear  anywhere  in  the  loop,  will 
reciuire  control  variables  to  be  local  to  the  iterative 
control,  will  allow  entry  only  at  the  head  of  the  loop,  and 
will  not  impose  excessive  overhead  in  clarity  or  run  the 
execution  costs  for  common  special  case  termination 
conditions  (e.g.,  fixed  number  of  iterations  or  elements  of 


an  array  exhausted).  ....Ft 

Termination  can  occur  anywhere  in  the  loop  T 

Multiple  terminating  predicates  are  possible  ....................  T 

Entry  permitted  only  at  the  loon  head  T 

Simple  cases  are  clear  and  efficient  T 

Control  variable  is  local  to  the  loop  F 

Control  value  is  efficiently  available  after  termination T 


The  CORAL  *6  requires  that  the  termination  condition  for  FOR 
statement  in  both  forms  fi.e.,  FOR  with  STEP  or  FOR  with  WHILE)  be 
provided  at  the  beqirninn  of  the  loop.  Faeh  time  the  loop  is  executed, 
this  termination  condition  is  evaluated  at  the  beginning  of  the  loop. 
The  user  is  allowed  to  use  an  IF-THEN  or  GOTO  statements  anywhere  in  the 
Iood  giving  him  the  facility  to  terminate  the  loop.  The  language  also 
allows  a loop  to  be  terminated  in  more  than  one  way,  permits  entry  only 
at  the  top  and  allows  simple  forms.  The  loop  control  variables  are  not 
local  to  the  loop,  they  must  be  declared  in  the  beginning  of  the 
procedure  in  which  the  loop  occurs.  The  value  of  the  control  variable 
is  available  after  the  termination  of  the  loop. 
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The  requirement  stating  that  the  control  variable  be  local  to  the 
looo  seems  to  be  in  conflict  with  the  requirement  that  all  variables  be 
explicitly  declared  before  use.  If  a control  variable  is  definea  Letore 
use  in  a loop,  it  will  also  be  defined  after  the  termination  of  the  loou 
and  thus  will  not  be  local  to  the  loop.  For  instance,  CORAL  (t>  requires 
that  all  control  variables  be  defined  at  the  beginning  of  the  procedure 
in  which  the  loop  is  present.  These  variables  are  not  local  to  the 
loop.  On  the  other  hand,  the  assumption  that  the  construct  FOR  1=1  THRU 
5 defines  1 is  also  wronn.  FOR  1=1  etc.  does  not  really  define  the 
construct  variable  I.  It  assigns  a value  to  the  variable  without 
defining  it.  The  attributes  of  I are  unknown  and  will  have  to  be 
defined  by  default  by  the  compiler. 


G5.  Recursive  as  well  as  nonrecursive  routines  will  be 
available  in  the  source  lanauaoe.  It  will  rot  be  possible  to 


define  procedures  within  the  body  of  a recursive 
procedure.  ....P 

No  recursive  procedures  within  recursive  procedures  ............. F 

(maximum  depth  of  recursion  can  be  specified)  .....F 

(Recursiveness  must  be  specified)  T 


The  CORAL  *6  language  allows  both  recursive  and  non-recursive 
procedures  in  the  definition.  If  a procedure  is  not  explicitly  declared 
to  be  RECURSIVE,  non-recursion  is  imolied.  There  is  no  language 
specified  restriction  that  a recursive  procedure  cannot  have  another 
recursive  procedure  within  its  definition. 

maximum  depth  of  recursion  is  also  not  specified. 

No  conflict  with  other  requirements. 


G6.  The  source  lanouage  will  provide  a parallel  processing 
capablity.  This  capability  should  include  the  ability  to 
create  and  terminate  (possible  pseudo)  parallel  processes  and 
for  these  processes  to  gain  exclusive  use  of  resources  during 


specified  portions  of  their  execution.  ....F 

Able  to  create  and  terminate  parallel  processes  ................ -F 

Process  can  oain  exclusive  use  of  resources  F 

No  parallel  routines  within  recursive  routines  F 

No  routines  within  parallel  routines  ..........F 

maximum  number  of  simultaneous  instances  are  declarable  F 
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(Access  rules  are  erforced) 


F 


CORAL  66  does  not  sunport  parallel  processinq. 

Extensive  modifications  to  the  lanouaue  capabilities  will  have  to 
oe  provided  to  meet  this  requirement.  The  lannuaqe  syntax  will  have  to 
include  facilities  for  task  initiation,  termination  and  resumption  and 
will  also  have  to  provide  for  waitinq,  event  related  interruot  handling, 
etc.  Tie  implementation  of  these  facilities  in  the  compiler  will 
require  expensive  interfaces  with  the  scheduler,  loader,  interrupt 
handler,  storage  allocator,  disc  and  file  handler,  and  other  portions  of 
the  operation  system.  Hardware  capabilities  (e.a.,  the  available 
storage,  single  or  mu l t i -pr oc s s i no  environment  etc.)  will  also  nave  to 
be  taken  into  account. 


G 7.  T h * exception  handliro  control  structure  will  permit  the 
user  to  cause  transfer  of  control  ana  data  tor  any  error  or 


excretion  situation  which  miqht  occur  in  a nropram.  ....F 

Ft  oar am  can  qet  control  for  any  exception  f 

Parameters  can  be  passed  f 

Can  cet  out  of  any  level  of  a rest  of  control  ...................  f 

Can  handle  the  exception  at  ary  level  of  control  ................  F 


CORAL  66  does  not  include  any  special  support  for  exception 
hand  lino. 

*Jo  conflict  with  other  requirements. 


G9.  There  will  be  source  lamuaae  features  which  permit 
delay  on  any  control  path  until  some  specified  time  or 
situation  has  occurred,  which  permit  specification  of  the 
relative  priorities  amona  parallel  control  paths,  which  qive 
access  to  real  time  clocks,  which  permit  asynchronous 
hardware  interrupts  to  he  treated  as  any  other  exception 


situation.  ....F 

Priority  specification  F 

Synchronization  via  wait/enable  operations  ......................  F 

wait  for  end  of  real  time  interval  .............................. F 

wait  for  end  of  simulated  time  interval  F 

wait  for  hardware  interrupt  . . . F 


p 
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(Can  enable  and  disable  interrupts)  F 


CORAL  66  does  not  support  any  of  these  capabilities. 
No  conflict  with  other  requirements. 
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HI.  The  source  language  will  be  free  format  with  an  explicit 
statement  delimiter,  will  allow  the  use  of  mnemonically 
significant  identifiers,  will  be  based  on  conventional  forms, 
will  have  a simple  uniform  and  easily  parsed  grammar,  will 
not  provide  unique  notations  for  special  cases,  will  not 
permit  abbreviation  of  identifiers  or  key  words,  and  will  be 


syntactically  unambiguous.  -...P* 

Free  format  with  statement  terminator  P* 

Mnemonic  identifiers  possible  f 

based  on  conventional  forms  T 

Simple  grammar  T 

No  special  case  notations  ...T 

No  abbreviations  of  identifiers  or  keywords  ..........T 

Unambiguous  grammar  P 


CORAL  66  very  nearly  meets  this  requirement.  It  allows  its 
statements  to  be  entered  in  free  format  anywhere  in  the  line  and 
terminated  by  a semi-colon.  There  are  a few  exceptions  to  free 
formatina  e.g.,  no  blanks  are  permitted  in  composite  operators  like  >= 
etc.  The  language  does  not  limit  the  legth  of  the  identifier  names,  but 
allows  the  compilers  to  optionally  select  the  first  1?  characters  to 
determine  the  uniqueness  of  the  identifiers.  The  user  can  thus  keeo  the 
names  more  mnemonically  significant,  and  the  compilers  can  keep  their 
syntax  checking  efficient.  CORAL  66  syntax  follows  conventional  forms 
and  left  to  riqht  scan  and  has  simple  grammar  rules  such  as  the 
parenthesis  are  evaluated  first  in  any  expression.  It  does  not  have 
soecial  notation  for  rare  cases,  nor  does  it  allow  abbreviations  of 
keywords  in  the  language  definition.  The  syntax  of  the  language  is 
generally  unambiguous  with  few  exceptions.  For  example,.  example,  the 
two  constructs  BIT  and  BITS  are  syntactically  very  close  to  each  other 
and  yet  have  significantly  different  usage.  Similarly,  the  constructs 
AND  and  MASK  have  the  same  meaning  in  mathematical  sense,  but  have 
significantly  different  usage  in  CORAL  46. 

Changes  to  the  language  definition  to  select  constructs  which  are 
significantly  distant  from  each  ether  to  represent  different  concepts  is 
necessary  to  meet  this  requirement.  Implementation  of  such  changes  will 
be  trivial  although  the  impact  on  user  programs  may  be  significant. 


H2.  The  user  will  not  be  able  to  modify  the  source  language 
syntax.  Specifically,  he  will  not  be  able  to  modify  operator 
hierarchies,  introduce  new  precedence  rules,  define  new  kev 
word  forms  or  define  new  infix  operator  precedences.  ....p 


I 


CORAL  6 6 
Requirement  M2 
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Although  the  facility  to  modify  language  syntax  and  operator 
hierarchies  or  the  capability  to  introduce  new  precedence  rules, 
definition  of  new  infix  operator  precedence,  etc.  is  not  available  or 
permitted  to  the  user,  the  language  does  allow  use  of  additional 
features  (including  keywords)  not  officially  within  the  CORAL  66 
language,  and  not  clashing  with  the  official  definition  or  with  each 
other,  to  be  implemented  in  the  compiler.  Hence  CORAL  66  only  partially 
meets  this  requirement. 

The  languaqe  definition  should  explicitly  forbid  additional 
keywords  to  be  introduced  in  the  language.  Extensibility  should  be 
permitted  only  via  procedure,  user  data  and  operator  definitions  without 
modification  of  existing  rules  of  the  language. 


H3 . The  syntax  of  source  lanauaqe  programs  will  be 
composable  from  a character  set  suitable  for  publication 
purposes,  but  no  feature  of  the  language  will  be  inaccessible 
using  the  64  character  ASCII  subset.  ....T 


All  features  of  the  language  can  be  constructed  utilizing  the  ASCII 
character  set.  In  certain  instances  the  languaqe  has  provided 
concessions  to  accommodate  representations  acceptable  to  ASCII  (e.g., 
the  conventional  "less  than  or  eaual  to"  symbol  is  replaced  by  <=). 

No  conflicts  with  other  reoui rements . 


H4. 

for 

for 

use 


The  language  definition  will  provide  the  format 
identifiers  and  literals.  These  will  include 
numbers  and  character  strings  and  a break  chara 
internal  to  identifiers  and  literals. 


ion  rules 
literals 
cter  for 


T 


Break  character  exists  T 

(Literals  are  self-identifying  as  to  type)  T 

(Pit-string  literals  for  any  type)  ............................ ..P 


The  language  specifies  rules  for  forming  identifiers  and  literals 
and  gives  examples.  It  allows  use  of  blank  character  in  identifiers 
without  acting  as  a terminator.  Hence  the  blank  can  be  used  as  a break 
character. 

The  type  of  CORAL  66  literals  is  determinable  from  their  syntax. 
Octal  literals  are  allowed,  but  hits  are  not  permitted  as  literals. 


CORAL  66 
Requirement  HA 


No  conflict  with  other  requirements. 


H5.  There  will  be  no  continuation  of  lexical  units  across 
lines,  but  there  will  be  a way  to  include  object  characters 
such  as  end-of-line  in  literal  strings.  ....f 


CORAL  66  does  not  allow  continuation  of  lexical  units  across  line 
No  conflict  with  other  requirements. 


H6.  Key  words  will  be  reserved,  will  be  very  few  in  number, 
will  be  informative,  and  will  not  be  usable  in  contexts  where 
an  identifier  can  be  used.  ....T 


A list  of  keywords  is  provided  in  an  Appendix.  There  are  only 
keywords.  They  are  all  reserved  and  cannot  be  used  as  identifiers. 

No  conflict  with  other  requirements. 


H 7.  The  source  language  will  have  a single  uniform  comment 
convention.  Comments  will  be  easily  distinguishable  from 
code,  will  be  introduced  by  a single  (or  possibly  two) 
language  defined  characters,  will  permit  any  combination  of 
characters  to  appear,  will  be  able  to  appear  anywhere 
reasonable  in  programs,  will  automatically  terminate  at 


end-of-line  if  not  otherwise  terminated,  and  will  not 
prohibit  automatic  reformatting  of  programs.  ....p* 

uniform  comment  convention  T 

Look  different  from  code  T 

Bracketed  by  one  or  two  characters  P 

Can  contain  any  characters  ,...P 

Can  appear  anywhere  reasonable  T 

Terminated  by  the  end  of  the  line  F 

Compatible  with  automatic  reformatting  ...T 


CORAL  66 
Requi  r ement  H7 
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There  are  two  ways  of  insertino  a comment  in  CORAL  66:  first,,  by 
startinn  with  COMMENT  and  terminating  with  a semi-colon.  In  this  case 
the  text  of  the  comment  cannot  contain  a semi-colon.  Second,  by 
enclosino  the  comment  within  round  brackets  immediately  following  a 
semi-colon  in  a program.  The  text  may  contain  brackets  provided  they 
are  matched.  In  either  form  of  comment,  the  end  of  line  is  ignored  in 
the  comment  and  a semi-colon  terminates  the  comment. 

To  meet  this  requirement  the  COWmFNT  form  of  comment  shall  have  to 
be  dropoed  since  it  does  not  start  with  one  cr  two  characters.  The 
language  should  allow  any  character,  including  a semi-colon,  in  the 
comment.  Furthermore,  the  comment  should  be  allowed  to  be  terminated  by 
the  end  of  line. 

Some  changes  will  be  reouired  to  all  existina  implementations  to 
accommodate  the  lanauane  changes. 


H8 . The  language  will  not  permit  unmatched  parentheses  nf 
any  kind.  . . . . T 


CORAL  66  does  not  allow  unmatched  parentheses  in  expressions  or 
comments  nor  does  it  permit  unequal  numbers  of  PEGINs  and  r NDs . 

Mo  conflict  with  other  requirements . 


H9 . There  will  be  a uniform  referent  notation.  ....f 


CORAL  66  encloses  array  subscriots  in  souare  brackets  and  function 
parameters  in  parentheses.  Tt,  therefore,  maintains  a syntactic 
difference  between  function  call  and  array  element  references.  In 
addition,  it  does  not  allow  functions  to  appear  on  the  left  hand  side  of 
an  assignment  statement  as  is  permitted  to  arravs.  Hence  the  language 
does  net  meet  this  requirement. 

Imr lementation  of  identical  syntax  for  arrays  and  functions  is  a 
simple  fix.  However,  allowing  functions  to  be  treated  like  pseudo 
variables  would  require  moderate  effort  to  implement. 


A 


CORAL  66 
Requirement  H10 


H10.  No  language  defined  symbols  appearing  in  the  same 
context  will  have  essentially  different  meanings.  ....T 

CORAL  66  symbols  are  unambiguous  and  have  the  same  meaning  in  all 
usages.  In  particular  CORAL  66  differentiates  between  :=  and  = and  does 
not  allow  parenthesized  parameters. 


Vo  conflict  with  other  requirements 


CORAL  (‘•b 
pequirement  II 


i 


II.  There  will  be  no  defaults  in  programs  which  affect  the 
prooram  loeic.  That  is,  decisions  which  affect  program  logic 
will  be  made  either  irrevocably  when  the  lanouage  is  defined 
or  explicitly  in  each  prooram. 


most  defaults  related  to  prooram  lo'-ic  are  specified  in  the  manual 
and  are  under  programmer  control  with  few  exceptions.  For  example,  the 
SWITCH  statement  does  not  specify  the  out  or  default  clause  which 
determines  the  tnansfer  of  control  in  t^e  event  the  value  of  the  switch 
is  either  zero  nr  exceeds  the  number  of  labels  provided  in  the 
declaration.  This  feature  is  i rrp  lement  at  i on  depenaent  and  can  alter  the 
flow  of  prooram  ccntrol. 

To  meet  this  requirement  the  OUT  or  OTHTRWISE  clause  should  be 
added  to  the  SWITCH  statement,  allowing  the  programmer  to  specify  the 
default  condition.  Implementation  of  this  feature  is  trivial. 


I?.  Defaults  will  be  provided  for  special  capabilities 
affecting  only  objert  representation  and  other  properties 
which  the  programmer  does  not  know  or  care  about.  Such 
defaults  will  always  mean  t*at  the  programmer  does  not  care 
which  choice  is  made.  The  proorammer  will  he  an l e to 


override  these  defaults  when  necessary.  ....P* 

Defaults  specified  for  don’t  care  cases  . . . T 

Pr corammer  can  override  the  defaults  ...........................  .p 


There  are  some  defaults  that  a proqranmer  may  care  about  and 
override,  but  there  are  some  others  which  he  cannot  control.  In  th*» 
first  category  comes  the  subscrirt  range  checking  which  is  not  checked 
by  default.  Put  the  programmer  has  the  option  to  srecify  that  code  be 
generated  to  check  it.  In  the  second  category  is  the  parameter  checking 
default  for  procedures.  No  run  time  parameter  checking  is  performed  and 
the  user  cannot  specify  that  this  be  don«. 

CORAL  bb  compilers  have  placed  prime  importance  on  run  time 
efficiency  and  compact  code.  The  language  has,  therefore,  deliberately 
avoided  features  such  as  dynamic  arrays  and  run  time  checking.  To  meet 
this  requirement,  an  option  should  be  provided  to  the  user  so  that  code 
is  generated  to  perform  run  time  checkinc  of  procedure  parameters  and 
other  features. 


CORAL  66 
Requirement  13 


AO 


13.  The  user  will  be  able 
variables  with  proqrams.  These 
specify  the  object  computer  mode 
object  machine  configuration. 


to  associate  compile  time 
will  include  variables  which 
and  other  aspects  of  the 


CORAL  66  does  not  provide  the  facility  to  provide  information  to 
compilers  regarding  the  characteristics  of  the  object  machine,  the 
configuration,  etc.  so  that  appropriate  code  could  be  generated  tor 
various  configurations. 


implementation  of  this  capability  would  require  selection  of  these 
"compile  time  variables"  for  the  language  and  processing  them  to 
generate  different  types  of  code  for  various  computers,  and 
configuration.  A determination  will  also  have  to  be  made  as  to  where  to 
place  these  features  in  the  program.  Implementation  of  these  features 
will  have  minimal  effect  on  syntax  and  semantic  analysis  phases  of 
compilation,  but  will  have  a significant  impact  on  the  code  generation 
phase  of  the  compilers. 


IA.  The  source  language  will  permit  the  use  of  conditional 
statements  <e.g.,  case  statements)  dependent  on  the  object 
environment  and  other  compile  time  variables.  In  such  cases 
the  conditional  will  be  evaluated  at  compile  time  and  only 
the  selected  path  will  be  compiled.  ,...F 


The  present  definition  of  CORAL  66  does  not  provide  for  control 
structures  which  can  be  used  for  conditional  compilation. 

Implementation  of  such  control  features  would  not  impact  other 
features  of  the  language.  The  existing  implementations  will  be  affected 
since  they  will  have  to  be  modified  to  process  the  object  environment 
related  conditionals  and  then  generate  code  only  for  the  selected  path. 


IS.  The  source  language  will  contain  a simple  clearly 
identifiable  base  or  kernel  which  houses  all  the  power  of  the 
language.  To  the  extent  possible,  the  base  will  be  minimal 
with  each  feature  providinn  a single  unique  capability  not 
otherwise  duplicated  in  the  base.  The  choice  of  the  base 
will  not  detract  from  the  efficiency,  safety,  or 
understandabi lity  of  the  language. 


T 


CORAL  66 
Requirement  15 


41 


The  official  definition  of  CORAL  66  represents  the  kernel  of  the 
language.  Plandford  extension  and  other  application  oriented  libraries 
have  been  added  to  expand  the  capabilities  of  the  language. 

No  conflicts  with  other  requirements. 


16.  Lanauaoe  restrictions  which  are  cependent  only  on  thf 
translator  and  not  on  the  object  machine  will  be  specified 
explicitly  in  the  language  definition.  ...,p 


The  CORAL  66  language  definition  sets  some  limits  on  som*>  of  its 
features  which  are  dependent  only  or  translators.  For  example,  it 
requires  only  one  or  two  dimensional  arrays,  sets  the  length  of  the 
identifiers  to  be  twelve  characters  fthe  extra  characters  are  legal  but 
will  he  ignored  by  the  compiler)  etc.  However,  it  does  not  specify  many 
other  limits  e.g.,  the  number  of  permissible  nested  loops,  number  of 
nested  parentheses  levels  in  expressions,  maximum  numter  of  formal  and 
actual  parameters,  maximum  number  of  identifiers  in  a pronram,  etc. 
Hence  it  only  partially  meets  the  requirement. 

To  implement  this  chanqe  would  reauire  a careful  analysis  of  user 
requirements  and  then  settinn  a limit  on  these  various  features  of  the 
language  in  the  official  definition.  effect  c*  such  standardized 
limitations  on  existing  implementations  will  f ••  minimal. 


17.  Lanquaae  restrictions  which  are  inherently  dependent 
only  on  the  object  environment  will  not  be  built  into  the 
language  definition  or  any  translator.  ....T 


COPAL  66  does  not  impose  restrictions  on  the  object  environment. 
It  does  not  state  limits  on  storage  reaui rements , tyres  of  perirherals, 
real-time  clock  etc.  In  fact,  it  allows  lancuaoe  features  such  os  the 
floating  point  to  be  omitted  from  the  implementation  if  adequate 
hardware  facilities  are  not  present. 

CORAL  66  should  make  the  availability  of  floatinq  point  data 
computations  mandatory  for  all  imolementat ions,  as  required  by  A2.  If 
the  computer  does  not  contain  the  floating  point  hardware,  the  option 
should  be  supplied  by  the  software  packaoe. 


CORAL  66 
Requirement  J1 


A? 


I 


J1.  The  language  and  its  translators  will  not  impose  run 
time  costs  for  unneeded  or  unused  generality.  They  will  be 


capable  of  producing  efficient  code  for  all  programs.  ....T 

No  efficiency  cost  for  unused  features  T 

Efficient  code  can  be  produced  for  all  features  ................. T 


Efficiency  in  terms  of  code  and  time  has  been  one  of  the  major 
considerations  in  CORAL  66  design  and  implementation.  Conceptually, 
CORAL  66  compilation  is  a one  pass  process.  The  insistence  that 
identifiers  are  fully  declared  or  specified  before  use  simplifies  the 
compiler  by  ensuring  that  all  relevant  information  is  available  when 
required.  The  syntax  of  the  language  is  transformable  into  one-track 
predictive  form,  which  enables  fast  syntax  analyzers  with  no 
back-tracking  to  be  employed.  Features  which  require  elaborate  storage 
in  the  object  machine  for  efficient  program  execution,  for  example 
dynamic  storage  allocation,  are  not  included  in  the  language.  Unless 
run  in  a special  diagnostic  mode,  a CORAL  66  compiler  is  not  expected  to 
generate  run-time  checks  on  subscript  bounds. 

In  general,  CORAL  66  language  features  are  simple,  clear  and 
concise  and  permit  efficient  code  generation. 

There  is  no  potential  conflict  with  other  requirements  but  to  meet 
all  the  requirements,  definition  will  have  to  be  significantly  modified. 
In  order  to  provide  for  range  checking  on  variable  subscripts  (A6,  DA), 
parameter  checkinq  on  procedures  <C6),  variable  numbers  of  arguments 
(C9),  user  definition  of  new  data  types  and  operators  (B11),  addition  of 
several  other  data  types  (e.g..  Boolean,  status  etc.)  the  complexity  of 
the  language  will  have  to  be  increased.  In  some  cases  it  is 
questionable  if  new  features  can  be  added  to  the  existing  lanquage 
syntax  without  loss  of  clarity  and  dependent  efficiency. 


J2.  Any  optimizations  performed  by  the  translator  will  not 
change  the  effect  of  the  program.  ,...T 

This  is  implied  in  language  definition  but  never  explicitly  stated. 


J3.  The  source  languaqe  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  including  machine 
lanquage  code  insertions.  ....F 


I 


(ORAL  66 
Requirement  J3 


In  order  to  meet  this  requirement  machine  language  insertions 
should  only  be  permissible  within  the  body  of  comoile  time  variables 
(14)  in  an  encapsulated  form.  CORAL  66  does  not  provide  for  comoile 
time  variables.  It  permits  easy  insertion  of  machine  code  between  BEGIN 
and  F N 0 statements.  Therefore,  at  present,  machine  code  can  be  easily 
inserted  within  the  body  of  executable  statements.  Hence  the  language 
does  not  meet  this  requirement. 

To  meet  this  requirement  the  language  definition  will  have  to 
define  "compile  time  variables",  their  syntax  ano  semantics  and  use. 
Procedures  for  Defining  characteristics  of  the  hardware  and  insertion  of 
machine  code  should  be  defined  also  within  their  body.  The  existing 
syntax  for  machine  code  insertions  will  have  to  be  dropped.  This  change 
will  imnact  all  existing  implementations. 


J4.  It  will  be  possible  within  the  source  language  to 
specify  the  object  presentation  of  composite  data  structures. 
These  descriptions  will  be  optional  and  encapsulated  and  will 
be  distinct  from  the  logical  description.  The  user  will  be 
able  to  specify  the  time/space  trade-off  to  the  translator. 
If  not  specified,  the  object  representation  will  be  optimal 
as  determined  by  the  translator. 


Encapsulated  specification  of  representation  possible 
Space/time  tradeoff  can  be  specified  


The  TABLE  declarations  in  CORAL  66  allow  a rroo rammer  to  control 
object  representation  of  composite  data.  The  user  has  the  facility  to 
specify  table  sizp,  word  and  bit  position  for  elements  and  their  length, 
and  even  the  bit  configuration  while  presetting  the  values  in  these 
tables.  The  language  also  allows  the  user  tc  pack  data  in  tables,  thus 
permitting  him  some  control  over  space  utilization.  Avoidance  of 
RECURSIVE  option  in  pronrams  also  saves  core  space.  Not  specifying  the 
special  mode  of  operation  which  allows  generation  of  cede  for  run  time 
checking  of  subscript  ranqes,  the  user  can  also  control  some  time  and 
space  also.  Other  features  of  the  language,  however,  do  not  allow  the 
user  to  control  space  or  time. 

To  fully  meet  this  requirement  some  additional  "compile  time 
variables”  can  be  provided  directing  the  compiler  to  save  (1)  core  or 
(?)  time.  The  user  should  be  able  to  specify  dense,  medium  cr  rare 
packing  of  data,  or  avoidance  cf  excessive  code  to  permit  faster 
execution  time.  Implementation  of  these  optimization  variables  will 
effect  existing  language  definition  and  all  existing  implementations. 


CORAL  66 
Requirement  J5 
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J5.  The  programmer  will  be  able  to  specify  whether  calls  on 
a routine  are  to  have  an  open  or  closed  implementation.  An 
open  and  a closed  routine  of  the  same  description  will  have 
identical  semantics.  . . . . F 

Ooen/closed  properties  can  be  specified F 

Open  and  closed  versions  have  the  same  semantics  ................F 

CORAL  66  only  allows  closed  routines  in  its  definition.  It  does 
not  allow  in-line  procedures  to  be  included  in  user  code.  Hence  it  does 
not  meet  this  requirement. 

The  syntax  of  the  procedure  definition  and/or  the  call  should  be 
modified  to  allow  for  open  or  closed  procedures.  The  user  will  exercise 
his  judgment  as  to  when  he  wants  to  use  open  or  closed  procedures.  It 
is  a simple  change,  but  will  affect  all  existing  implementations. 


CORAL  66 


45 


Fxtraneous  Features 

«e  recommend  that  the  following  features  or  CORAL  66,  not  required 
by  the  Tinman,  be  kept: 

• Parameterized  MACRO  capability,  with  nesting.  This 
gives  the  funct ional ity  of  open  subroutines,  as  called 
for  by  Tiniran. 

* Fxplicit  type  conversions  of  any  data  unit  (typed  or 
untyped).  This  can  be  used  to  control  the  scaling  on 
intermediate  fixed  point  calculations  (e.o., 

FIXED (1 ?, 5) (ABC  - X Y7)  specifies  that  the  result  of 
the  subtraction  is  to  te  treated  as  though  it  had  5 
fractional  bits)  and  to  override  any  implicit  type 
conversions.  The  latter  consideration  would  no  longer 
be  valid  if  the  implicit  type  conversions  were  removed 
from  the  language. 


we  recommend  that  the  following  features  of  CORAL  66,  not  required 
by  the  Tinman,  be  deleted: 

* Table  word  referencing  and  presettinq,  without 
consideration  of  the  table  structure.  This  is  too 
hardware  dependent  and  can  seriously  inhibit 
portability.  It  is  also  a means  to  defeat  tyne 
checking. 


* "Anonymous"  referencing,  which  gives  a capability  of 
addressing  machine  words.  This  is  too  hardware 
dependent,  defeats  type  checkino,  and  its  only 
legitimate  use  seems  to  be  as  a rudimentary  pointer 
mechanism.  (It  is  easy  to  think  of  some  appallino 
illegitimate  uses.)  Presumably  this  feature  would  be 
unneeded  if  a full-blown  pointer  capability  is 
present. 

* Statement  switches.  These  are  elaborations  of  the 
GOTO. 


COPAL  66 
retained,  but 
(encapsulated) 
That  feature 
operators  MASK 


has  one  hardware  feature  which  should  probably  be 
it  should  be  required  that  each  use  be  bracketed 
by  statements  which  point  out  the  machine  dependency, 
is  word  logic,  i.e.,  bit  manipulation  of  data  usinq  the 
(and),  UNION  (inclusive  or),  and  DIFFER  (exclusive  or). 


■ 
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Summary 

CORAL  66  is  a general  purpose  prooramming  language  well  suited  for 
use  on  small  and  medium  sized  computers.  The  kernel  of  the  language 
provides  facilities  to  perform  fixea  point  computation,  one  or  two 
dimensional  array  manipulation,  short  circuit  evaluation  of  boolean 
operations,  mechanisms  tor  explicit  conversions  of  untyped  expressions 
to  intpoer,  fixed,  or  floating  point  numbers,  type  checking  and  matchinq 
of  formal  and  actual  parameters,  call  by  value  and  call  by  reference, 
literals  for  all  languaoe  defined  data  types,  capability  of 
initialization  of  variables  at  the  time  of  their  definition,  a 
•location*  option  which  can  be  used  as  a pointer  mechanism,  and  fixing 
the  sco^  of  identifiers  at  compile  time.  CORAL  66  allows  interfaces 
with  assembly  language  routines.  It  provides  for  an  optional  definition 
of  recursive  procedures.  The  syntax  of  the  language  allows  free 
formatting,  is  simple  and  permits  the  user  to  specify  mnemonic  names  of 
any  lenoth.  (The  translator  is  required  to  check  only  the  first  eight 
characters  to  establish  uniqueness.)  The  smallness  of  the  language  and 
the  simplicity  of  its  constructs  allow  efficient  code  to  be  generated. 

In  addition  to  the  lanouaae  kernel,  there  are  some  well-known 
extensions  to  the  language,  such  as  the  Plandford  extension.  This 
extension  provides  for  bit,  byte,  or  character  definitions  and  strino 
manipulation.  The  library  option  of  the  language  permits  application 
oriented  procedures  to  be  available  for  use  by  different  projects. 

However,  there  are  a number  of  characteristics  required  by  the 
Tinman  which  CORAL  66  does  not  have.  For  instance,  there  is  no 
provision  for  parallel  processing,  exception  handling,  input/output,  or 
real-time  processing.  The  lanouaqe  does  not  allow  the  user  to  define 
new  data  types  or  new  operators,  nor  does  it  allow  specification  of 
operations  for  built-in  data  types.  Enumeration  types  are  not 
supported.  Boolean  type  data  is  not  supported.  No  provision  is  made  in 
the  language  for  specification  of  qlobal  precision  for  arithmetic 
computation.  The  floating  point  data  type  has  been  made  optional  in  the 
language,  and  the  exponentiation  operation  is  not  defined.  The  language 
does  not  require  that  rounding  be  explicit  nor  does  it  specify  that  the 
truncation  must  take  place  from  the  right  in  all  computations.  The 
language  permits  implicit  type  conversions  and  mixed  mode  arithmetic 
(which  can  be  interpreted  as  a case  of  implicit  type  conversion). 
Furthermore,  the  language  syntax  does  not  allow  specification  of  the 
ranges  of  variables  nor  are  there  language  defined  rules  for  operator 
precedence  or  expression  evaluation.  There  is  no  provision  in  the 
language  to  define  and  store  data  in  compools.  The  SWITCH  instruction 
provided  in  the  language  does  not  support  structured  programming 
practices  because  the  control  does  not  return  to  the  statement  following 
the  SWITCH.  The  SWITCH  statement  also  does  not  provide  for  an  OTHERWISE 
clause.  The  GOTO  statement  is  unrestricted  and  allows  transfers  of 
control  to  labels  outside  the  procedure  in  which  the  60T0  occurs.  No 
conditional  compilation  facility  is  available  to  generate  code  for  only 
the  selected  path  of  conditional  control  statements.  Nor  is  there  a 
facility  to  allow  a user  to  specify  if  he  wanted  an  op*n  or  closed 
implementation  for  his  procedures. 
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There  is  no  easy  way  to  make  CORAL  66  meet  the  Tinman  reoui rements . 
To  do  so  would  require  deletion  and  modification  of  existing  features 
and  the  addition  cf  several  new  features.  The  modified  version  of  the 
lanouaqe  will  look  nowhere  near  the  existing  version  of  CORAL  66.  User 
resistance  to  change  will  also  be  significant  because  the  new  language 
may  he  so  distant  from  the  existing  version  that  in  upgrading  of 
existing  programs  to  the  new  version  might  not  be  simple  or  even 
nossi b le . 

However,  if  the  objective  of  uparadinq  the  existing  proarams  is 
discarded  and  the  new  languaqe  is  designed  to  meet  the  Tinman 
reauirements  using  selected  features  from  CORAL  66  as  a kernel 
(e.q.  procedure  definition  and  passinq  capabilities,  the  recursive 
option,  FOR  loop,  DEFINE  capability,  PRESET  option,  explicit  type 
conversion,  explicit  declarations,  etc.),  then  it  is  possible  to  desian 
an  extensible  lanquage  which  has  similarities  to  CORAL  66.  The 
similarities  would  be  only  of  a fairly  aeneral  nature,  however,  and  the 
new  language  would  be  quite  different  from  CORAL  66.  Such  an  effort 
would  be  of  major  proportions. 
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Introduction 

This  report  gives  a comparison  of  the  language  CS-4  to  the  Tinman 
languane  requirements  (Department  of  Defense  Requirements  for  Hioh  Order 
Computer  Proorammina  Languages,  "Tinman"  - 1 march  1976,  Section  IV). 
For  the  purposes  of  this  comparison,  CS-4  is  considered  to  be  defined 
by: 

CS-4  Lanquaae  Reference  Manual  and  ^Deration  System 
Interface 

Intermetrics,  Inc. 

Cambridge,  Mass. 

October,  1975 

Tinman  contains  78  language  requi rements . This  report  compares 
CS-4  to  each  requirement  individually.  If  a requirement  is  totally 
satisfied,  the  accompanying  text  is  a summary  cf  the  oarticular 
mechanism  used.  (Occasionally  no  text  is  needed  if  a requirement  is 
totally  satisfied.)  If  a requirement  is  not  totally  satisfied,  the  text 
consists  of  a summary  o*  the  shortcomings  and  such  items  as  the  scope  of 
the  changes  necessary  to  fully  meet  the  requirement  and  the  impact  of 
these  changes  on  existinq  implementations. 

Each  Tinman  requirement  begins  with  an  introductory  paragraph. 
These  paragraphs  are  reproduced  in  this  report.  In  many  cases  they  are 
followed  by  several  single-line  summaries  of  features  in  the  are?  of  the 
requirement.  Usually  these  are  features  which  are  specifically  called 
for  in  the  requirement.  A feature  enclosed  in  parentheses,  however,  is 
one  which  the  reviewers  thought  possibly  desirable,  even  though  not 
called  for  in  the  requirement. 

Symbols  placed  beside  the  introductory  paragraph  and  the  individual 
features  indicate  the  degree  to  which  the  requirement  or  feature  is 
satisfied  by  the  lanauage.  The  symbols  and  their  meanings  are: 

T - Totally  satisfied 

P - Partially  satisfied 

F - Fails  (not  satisfied  at  all) 

U - Unclear  from  the  documentation 

P ♦ - Almost  totally  satisfied 

P-  - Orly  slightly  satisfied 

N/A  - Not  applicable  (used  only  for  individual 
features  when  the  requirement  is  not  satisfied 
at  all) 

(The  symbols  p,  P+,  and  p-  will  often  be  used  with  requirements  which 
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are  stated  in  one  of  the  forms  "There  will  be  no..."  or  "All...",  even 
though  only  T or  F are  technically  applicable  in  these  cases.) 

The  report  concludes  with  two  summaries.  The  first  is  of  the 
features  of  CS-4  which  are  extraneous  to  Tinman  and  the  desirability  of 
retaining  each  of  them.  The  second  is  of  the  language  as  a whole  and 
the  desirability  of  modifyina  it  to  bring  in  into  line  with  the  Tinman 
requirements . 


r 
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Requirement  A1 


A1 . The  language  will  be  typed.  The  type  Cor  mode)  of  all 
variables,  components  of  composite  data  structures, 
expressions,  operations,  and  parameters  will  be  determinable 
at  compile  time  and  unalterable  at  run  time.  The  language 
will  require  that  the  type  of  each  variable  and  component  of 
composite  data  structures  be  explicitly  specified  in  the 
source  proarams.  ...-T 


The  CS-4  term  for  "type"  is  "mode",  the  requirement  is  met  <0.  1). 


A2.  The  language  will  provide  data  types  for  integer,  real 
(floating  point  and  fixed  point).  Boolean  and  character  and 
will  provide  arrays  (i.e.,  composite  data  structures  with 
indexable  components  of  homogeneous  type)  and  records  (i.e., 
composite  data  structures  with  labeled  components  of 
heterogeneous  type)  as  type  generators.  ....P* 


Integer  - T 

Floating  Point  -T 

Fixed  Point  P- 

Boolean . T 

Character  Strino  ...T 

Arrays  T 

Records  T 


Not  fully  met.  CS-4  has  no  fixed  point  type;  it  has  only  fraction 
(pp.  27,  5 3 f f .) 

CS-4  does  have  the  following  types: 

Inteqer  (pp.  37-44) 

Floating  point  (pp.  44-5P) 

Boolean  (pp.  31-37) 

Character  strino  (op.  100-113) 

Array  (pp.  82-93) 

Record  (called  STRUCTURF;  np.  94-99) 

Adding  fixed  point  to  the  lanquaqe  would  be  of  moderate  difficulty. 
Designing  and  implementing  (and  explaining)  the  necessary  scaling  rules 
is  never  an  easy  job. 


A3.  The  source  language  will  require  global  (to  a scope) 
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specification  of 
and  will  permit 
variables.  This 
maximum  precision 
minimum  precision 


the  precision  for  floating  point  arithmetic 
precision  specification  for  individual 
specification  will  be  interpreted  as  the 
required  by  the  program  logic  and  the 
to  be  supported  by  the  object  code. 


...P 


Global  arithmetic  precision  specification  mandatory  .F 

Individual  variable  precision  specif ication  permitted  T 


Not  fully  met.  6lobal  arithmetic  precision  cannot  be  specified, 
and  it  is  machine  dependent  (p.  204). 

Precision  can  be  specified  for  individual  variables  (pp.  44-4B). 

The  addition  of  qlobal  arithmetic  precision  specification  would  not 
be  much  of  a change  to  the  language,  but  it  would  probably  cost  3-6  man 
months  per  target  machine  to  write  the  necessary  library  routines. 


A4 . Fixed  point  numbers  will  he  treated  as  exact  quantities 
which  have  a range  and  a fractional  step  size  which  are 


determined  by  the  user  at  compile  time.  scale  factor 
management  will  be  done  by  the  compiler.  ....F 

Treated  as  exact  quantities  F 

Range  and  step  size  determined  at  compile  time  .....F 

Scalino  handled  automatically  f 


Not  met;  CS-4  has  no  fixed  roint. 

For  the  scope  of  changes  necessary  to  add  this  feature,  see  the 
evaluation  of  A2. 


A5.  Character  sets  will  be  treated  as  any  other  enumeration 


type . . . . . F 

New  sets  can  be  defined  as  enumeration  types  .................... F 

ASCII  and  EBCDIC  are  provided  F 

(Conversion  capability  between  sets  is  available)  F 

Not  met.  New  character  sets  cannot  be  defined.  Only  ASCII  is 


provided  (p.  IDO).  There  is  no  conversion  between  character  sets 
(obviously,  because  there  is  only  one). 


CS-4  3 

Requi rement  *5 

It  would  be  relatively  easy  to  add  the  required  capability. 


A6.  The  language  Mill  require  user  specification  of  the 
number  of  dimensions*  the  ranqe  of  subscript  values  for  each 
dimension*  and  type  of  each  array  component.  The  number  of 
dimensions*  the  type  and  the  lower  subscript  bound  will  be 
determinable  at  compile  time.  The  upper  subscript  bound  will 
be  determinable  at  entry  to  the  array  allocation  scope.  ...,pt 

Number  of  dimensions  is  fixed  at  compile  time  T 

Type  is  fixed  at  compile  time T 

Lower  subscript  bound  is  fixed  at  compile  time  F 

Upper  subscript  bound  is  fixed  at  scope  entry  T 

Subscripts  only  integers  or  from  an  enumeration  type  .T 

Subscripts  will  be  from  a contiguous  range  T 

Partially  met.  The  lower  subscript  bound  is  variable  at  run-time 
(p.  83)  - a violation. 

modification  to  meet  the  requirement  would  be  trivial. 


A 7.  The  language  will  permit  records  to  have  alternative 
structures*  each  of  which  is  fixed  at  compile  time.  The  name 
and  tyre  of  each  record  component  will  be  specified  by  the 
user  at  compile  time.  ....f 

Alternative  structures  for  records  are  possible  n/a 

Discrimination  condition  may  be  any  Poolean  expression N/A 

Not  met.  Records  do  not  have  alternate  structures  (p.  *7).  A 
component  may  be  of  a discriminated  union  type*  but  strictly  speaking* 
this  is  a different  capability  fsee  FA). 

meeting  the  requirement  would  cause  a fairly  major  change*  as  CS-4 
solves  the  problem,  in  a different  way. 
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B1.  Assignment  and  reference  operation  will  be  automatically 
defined  for  all  data  types  which  do  not  manage  their  data 
storage.  The  assignment  operation  will  permit  any  value  of  a 
given  type  tc  be  assigned  to  a variable,  array,  or  record 
component  of  that  type  or  of  a union  type  containing  that 
type.  Reference  will  retrieve  the  last  assigned  value.  ....T 

Automatically  defined  for  any  type  (except...)  T 

Available  for  individual  components  T 

(Assignment  and  reference  via  functions)  F 


net.  see  pp.  25-26,  3f,  39,  50,  60,  77,  89,  97,  104,  118,  163-164. 


82.  The  source  language  will  have  a built-in  operation  which 
can  be  used  to  compare  any  two  data  objects  (regardless  of 
type)  for  identity.  ....P^ 

Partly  met.  There  is  an  identity  predicate  (called  COMPARE)  for  every 
type;  it  does  a component  by  component  comparison  for  arrays  and 
records;  and  it  works  also  for  defined  types  (see  pp.  31,  37,  50,  60, 

77,  90,  97,  105,  118,  164-165). 

However,  the  predicate  does  not  allow  comparing  objects  of  possibly 
different  type,  except  for  UNION. 

Change  to  meet  the  requirement  would  be  relatively  minor. 


P3.  Relational  operations  will  be  automatically  defined  for 


numeric  data  and  all  types  defined  by  enumeration.  ....p> 

Puilt-in  for  all  numeric  and  enumeration  types  T 

^Ordering  can  be  inhibited  when  desired  ..............F 


Partly  met.  See  pp.  34,  42,  52,  62-63,  80.  There  is  no  way  to 
declare  unordered  types. 

A very  simple  change  would  be  needed  to  provide  unordered 
enumeration  types.  The  PRFO  and  SUCC  functions  would  clearly  be 
undefined  for  such  types. 
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HA.  The  built-in  arithmetic  operations  will  include: 
addition,  subtraction,  multiplication,  division  (with  a real 
result),  exponentiation,  integer  division  (with  inteoer  or 
fixed  point  arguments  and  remainder),  and  negation.  ....P+ 

Addition  T 

Subtraction  ..T 

Multiplication  T 

Division  with  real  result  ......T 

Exponentiation  T 

Inteoer  and  fixed  point  division  with  remainder  P 

Negation  T 

Partially  met  (see  op.  67-75).  Violation:  Integer  division  has  no 
remainder  (p.  7?),  and  there  is  no  modulus  operator  (pp.  A1,  A3). 

A very  easy  addition. 


B 5 . Arithmetic  and  assianment  operations  on  data  which  are 
within  the  range  specifications  of  the  program  will  never 
truncate  the  most  significant  dioits  of  a numeric  Quantity. 


Truncation  and  rounding  will  always  be 
significant  dirits  and  will  never  he  implicit 
and  fixed  point  numbers.  Implicit  roundi 
specified  precision  will  be  allowed  for 
numbers  . 


s be  on  the  least 
rlicit  for  inteeers 
rounding  beyond  the 
for  floating  point 


Never  from  the  left  for  data  within  range  ................ 

Never  on  the  right  for  inteqer  and  fixed  point  

Implicit  floating  point  rounding  beyond  precision  allowed 
(Run  time  checks  can  be  avoided)  


Met.  See  pp.  39,  5Ci,  60,  67-75. 


66 . The  built-in  Boolean  operations  will  include  "and", 
"or”,  "not",  and  "xor".  The  operations  "and"  and  "or"  on 
scalars  will  be  evaluated  in  short  circuit  mode. 


Short-circuit  and  T 

Short-circuit  or  T 

Not  T 

xor  t 
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Pet  (see  pp.  32-33).  In  addition  to  the  required  operators,  CS-4 
also  has  nAND,  NOR,  EQV,  and  IMP. 


87.  The  source  language  will  permit  scalar  operations  and 
assignment  on  conformable  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  logical 


structure.  ....F 

Scalar  operations  on  arrays  F 

Assignment  between  records  and  arrays  of  conformable  type  f 


Not  met.  There  are  no  scalar  operations  on  arrays  (p.  93),  and 
assinnment  is  legal  only  if  source  and  sink  are  of  the  same  type 
(p.  125). 

Change  should  not  hr  too  hard,  as  component  by  component  comoare 
operations  are  already  available. 


88 . There  will  be  no  implicit  type  conversions  but  no 
conversion  operation  will  be  required  when  the  type  of  an 
actual  parameter  is  a constituent  of  a union  type  which  is 
the  formal  parameter.  The  language  will  provide  explicit 
conversion  operations  among  integer,  fixed  point  and  floating 
point  data,  between  the  object  representation  of  numbers  and 
their  representations  as  characters,  and  between  fixed  point 


scale  factors.  ....p 

No  implicit  conversions  F 

Explicit  between  integer,  fixed  point,  and  floating  point  P 

Explicit  between  fixed  point  scale  factors  ...F 

(Explicit  between  integer  and  Boolean)  F 

(Explicit  between  inteqer  and  enumerated  types)  T 

(Explicit  between  different  enumerated  types)  P- 


Partially  met.  Violations:  The  arithmetic  operations  all  work  with 
mixed  mode  operands  (pp . 71ff)  which  can  be  interpreted  as  implicit  type 
conversions.  There  are  no  fixed  point  conversions. 


Required  explicit  conversions  are  discussed  on  pp.  40,  51,  56, 


t 


' 


1 


1f)d. 


and 
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The  required  change  to  the  language  would  be  fairly  minor,  but  many 
would  argue  that  it  is  unnecessary  and  even  undesirable. 


89.  Explicit  conversion  operations  will  not  be  required 
between  numerical  ranges.  There  will  be  a run  tire  exception 


condition  when  any  integer  or  fixed  point  value  is 
truncated.  ....T 

Implicit  conversion  between  ranges  T 

Exception  condition  on  integer  and  fixed  point  truncation' u 


Met.  See  pp.  39,  50,  60,  67-75. 


BIO.  The  base  language  will  provide  operations  alio. inn 
programs  to  interact  with  files,  channels,  or  devices, 
including  terminals.  These  operations  will  permit  sendina 
and  receiving  both  data  and  control  information,  will  enable 
programs  to  dynamically  assign  and  reassiqn  I/O  devices,  will 
provide  user  control  for  exception  conditions,  and  will  not 


be  installation  dependent.  ....p 

Sending  and  receiving  of  data  .......T 

Sending  and  receiving  of  control  information  F 

Dynamic  device  assignment  F 

User  exception  condition  control  T 

Installation  independence  u 

(Data  formatting  capability)  T 

(Reading  and  writing  of  bit  strings)  .....F 


Partly  met.  (see  Part  II,  pp.  1-?D>. 

Violations:  (1)  Mo  provision  for  sending  and  receiving  control 
information  as  such.  (?)  No  dynamic  device  assignment. 

It  is  unknown  from  the  documentation  if  the  capability  is 
installation-independent.  ■' V 

It  would  be  an  easy  to  moderate  change  to  the  language  to  include 
these  missing  features. 


B11.  The  language  will  provide  operations  on  data  types 
defined  as  power  sets  of  enumeration  types  (see  E6).  These 
operations  will  include  union,  intersection,  difference. 


complement,  and  an  element  predicate.  ....p* 

Union  ........T 

Intersection  T 

Difference  .......F 

Comp lement  ,...T 

Membership  predicate  ...T 

(Set  inclusion)  .T 


Not  fully  met  (see  po.  253-P56).  There  is  no  difference  operation; 
A-R  can  be  written  indirectly  as  NOT  (A  IMP  R). 

Trivial  change  necessary. 
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Requirement  Cl 

Cl.  Side  effects  which  are  dependent  on  the  evaluation  order 
amonc  the  arguments  of  an  expression  will  be  evaluated 
left-to-ripht . ....T 

Side  effects  must  occur  in  lef t-to-r i ght  order  .T 

(Embedded  assionments)  F 

Met  (p.  28),  although  we  wonder  whether  implementations  will  in 
fact  be  so  strict. 


C2-  which  parts  of  an  expression  constitute  the  operands  to 
each  operation  within  that  expression  should  be  obvious  to 
the  reader.  There  will  be  few  levels  of  operator  hierarchy 
and  they  will  be  widely  recognized.  ....P* 

Few  precedence  levels  T 

ho  user-defined  precedence  levels  T 

Operands  of  an  operation  are  obvious  ........................... .p 

Partly  met.  There  are  only  7 precedence  levels  (unary  ♦ and  - are 
of  higher  precedence  than  * or  /)  (see  pp.  211-214).  There  are  no 
user-defined  precedence  levels. 

Violation:  The  operands  of  an  operation  are  not  always  obvious, 
because  A/B/C  and  A/B«C  are  permitted  (p.  67). 

It  would  be  an  easy  change  to  require  explicit  parenthesizing  in 
the  above  cases. 


C 3.  Expressions  of  a given  type  will  be  permitted  anywhere 
in  source  programs  where  both  constants  and  references  to 
variables  of  that  type  are  allowed.  ....P* 

1 

i \ 

Partly  met.  There  is  however  an  odd  restriction  on  Boolean 
expression  forms:  I > 0 AND  P is  not  permitted;  it  must  be  written 
(I  > 0)  AND  P (pp.  34-35). 

The  change  appears  so  easy  that  we  wonder  whether  there  is  some 
hidden  difficulty  arising  from  a specialized  parsing  technioue. 
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C A . Constant  expressions  will  be  allowed  in  proqrams 
anywhere  constants  are  allowed,  and  constant  expressions  will 
be  evaluated  before  run  time.  ....I 


Met.  (p.  173). 


C5.  There  will  be  a consistent  set  of  rules  applicable  to 
all  parameters,  whether  they  be  for  procedures,  for  types, 
for  exception  handling,  for  parallel  processes,  for 
declarations,  or  for  built-in  operators.  There  will  be  no 
special  operations  (e.g.,  array  substructur inq)  applicable 
only  to  parameters.  Uniformity  and  consistency  contribute  to 
ease  of  learning.  ....P 

Parameter  rules  consistent  in  all  contexts  ..................... .T 

No  special  operations  applicable  only  to  parameters  ..F 


Partly  met  (see  pp.  1A0-1A7,  150-151,  160-16?,  170-17?).  The 
violation  is  that  the  operation  of  dynamically  binding  a procedure  name 
to  a procedure  body  is  available  only  in  the  parameter  context. 

It  is  not  a violation  that  initi al i ration  is  allowed  for  (C0PY0) 
procedure  parameters  (pp.  1A0-1A1),  but  not  for  parameters  to  a mode 
declaration  <pp.  160-161),  because  C0PY0  parameters  are  not  allowed  in 
the  latter  case.  Permittino  fewer  options  in  some  cases  is  not  an 
inconsistency. 

To  bring  CS-A  into  conformance  with  this  requirement  would  be  a 
major  change.  To  do  it  right,  a pointer  mechanism  should  be  added. 


C6.  Formal  and  actual  parameters  will  always  agree  in  type. 
The  number  of  dimensions  for  array  parameters  will  be 
determinable  at  compile  time.  The  sire  and  subscript  range 
for  array  parameters  need  not  be  determinable  at  compile 
time,  but  can  be  passed  as  part  of  the  parameter. 

Actual  and  formal  parameters  will  agree  in  type  

Rank  of  parameter  arrays  is  fixed  at  compile  time  

Parameter  array  size  and  subscript  range  can  be  passed  ...... 


CS-4 

Requirement  C6 


11 


I X 


| 


met  (op. 


143-147). 


C7.  There  will  be  only  lour  classes  of  formal  parameters. 
For  data  there  will  be  those  which  act  as  constants 
representinq  the  actual  parameter  value  at  the  time  of  call, 
and  those  which  rename  the  actual  parameter  which  must  be  a 
variable.  In  addition,  there  will  be  a formal  parameter 
class  for  specifyinq  the  control  action  when  exception 


conditions  occur  and  a class  for  procedure  parameters.  ....P 

Act  as  constants  (call  by  value  plus)  F 

Act  as  variables  (call  by  reference)  ............................ T 

Exception  control  

Procedure  parameters  .T 

(Act  as  variables,  but  call  by  value)  T 

(Act  as  variables,  result  parameter)  T 


Partly  met  (see  pp.  139-153). 

Violations:  There  is  no  way  to  declare  that  a parameter  is  a 
constant  within  the  procedure  (o.  139-151).  There  is  a way  to  handle 
except  ion  conditions  by  a sort  of  implicit  parameter  which  is  a 
"signal-handling"  procedure.  When  an  exception  condition  occurs,  a 
search  is  made  through  the  dynamic  control  chain  for  a procedure  which 
can  handle  this  exceotion,  so  such  procedures  are  in  effect  implicit 
parameters.  They  may  also  presumably  be  explicit.  However,  there  is  no 
special  format  parameter  class  for  exception  handlinq,  so  strictly 
speakina,  CS-4  does  not  meet  this  part  of  the  requirement, 
(p.  151-155).  See  also  G7. 

CS-4  also  has  formal  parameter  classes  which  the  Tinman  disallows: 
Call  by  value  and/or  result  (cory  in  and  copy  out),  with  no  restriction 
against  change  within  the  procedure. 

Scope  of  necessary  change:  major.  The  procedure  passinq  mechanism 
is  one  of  a language's  most  vital  organs. 


C8.  Specification  of  the  type,  range,  precision,  dimension, 
scale,  and  format  of  parameters  will  be  optional  in  the 
procedure  declaration.  None  of  them  will  be  alterable  at  run 


time.  ....l’ 

Above  properties  optional  F 
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Above  properties  are  fixed  at  run  time  T 


Partly  met.  Formal  parameter  attributes  are  not  optional  in  CS-4; 
a formal  parameter  must  be  declared  with  a full  "mode  - invocation" 
(pp.  139-140).  In  the  discussion  of  open  procedures  <pp.  14F-149),  it 
is  implied  that  the  formal  parameter  attributes  can  be  left 
"jnresolved",  but  this  apparently  contradicts  this  syntax  on  p.  140. 

Scope  of  change:  Fairly  major,  if  done  right.  One  wants  to  leave 
unspecified  just  those  parameter  attributes  not  needed  directly  in  the 
procedure;  the  operations  to  be  applied  to  the  parameters  should  be 
specified,  and  this  is  a whole  new  notion  of  "type". 


C9.  There  will  be  provision  for  variable  numbers  of 
arguments,  but  in  such  cases  all  but  a constant  number  of 
them  must  be  of  the  same  type.  Whether  a routine  can  have  a 
variable  number  of  arguments  must  be  determinable  from  its 
description  and  the  number  of  arguments  for  any  call  will  be 


determinable  at  compile  time.  ....P- 

Variable  number  of  arguments  possible  P- 

All  but  a constant  number  of  arguments  have  the  same  type  F 

Number  of  arguments  in  each  call  is  fixed  at  compile  time  .......T 


Partly  met.  The  number  of  actual  parameters  may  vary  if  the 
matching  is  by  keyword,  but  the  number  of  formal  parameters  is  fixed. 
That  is,  if  the  actual  parameter  is  not  qiven,  then  a user-specified 
default  value  is  assigned  to  the  formal  parameter.  There  is  no  direct 
way  to  get  a count  of  the  number  of  actual  parameters  that  were  supplied 
on  a particular  call.  This  does  not  meet  the  needs  of,  for  example,  a 

print  procedure,  so  this  part  of  the  requirement  is  only  partially 

satisfied.  (p.  145). 

There  is  no  restriction  to  the  same  type  for  optional  parameters, 
(p.  143-145). 

Scope  of  change:  moderate  to  difficult,  depending  on  the 

flexibility  desired. 
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D1 . The  user  will  have  the  ability  to  associate  constant 
values  of  any  type  with  identifiers.  ....T 


f*et  (np.  15-16),  although  in  a very  awkward  fashion.  A range 
specification  must  be  aiven  for  constants' 


02.  The  language  will  provide  a syntax  and  a consistent 
interpretation  for  constants  of  built-in  data  types.  Numeric 
constants  will  have  the  same  value  (within  the  specified 


precision)  in  both  programs  and  data  (input  or  output).  ....P 

Literals  for  all  built-in  types  ................................. T 

Consistent  interpretation  in  program  and  data  .................. .U 


At  least  partly  met.  There  are  literals  for  all  built-in  tyoes 
(pp.  2-9) . However,  the  input  conversion  description  does  not  mention 
accuracy  (Part  II,  p.  18),  so  it  is  unknown  whether  this  part  of  the 
requirement  is  met. 


D3.  The  lanauape  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  part  of  their  declaration. 
Such  variables  will  be  initialized  at  the  time  of  their 
apparent  allocation  (i.e.,  at  entry  to  allocation  scope). 


There  will  be  no  default  initial  values.  ....P» 

Initial  value  can  be  speci tied  as  part  of  the  declaration  T 

Initialization  occurs  at  allocation  scope  entry  ...T 

No  default  initial  values  F 


Almost  completely  met  (pp.  18-19).  An  object  of  a user-defined 
type  may  have  a default  initial  value  (p.  166).  This  is  technically  a 
violation,  but  it  seems  necessary. 


D4 . The  source  lannuage  will  require  its  users  to  specify 
individually  the  range  of  all  numeric  variables  and  the  step 
size  for  fixed  point  variables.  The  rang*  specifications 
will  be  interpreted  as  the  maximal  range  of  values  which  will 
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be  assigned  to  a variable  and  the  minimal  range  which  must  be 
suDDorted  by  the  obiect  code.  Range  and  step  size 
specifications  will  net  be  interpreted  as  defining  new 


types.  . . . . P» 

Numeric  variable  range  specification  mandatory  .................. T 

Fixed  point  variable  step  size  specification  mandatory  ...... ....F 

Ranoe  and  step  size  specifications  do  not  define  a new  type  .....T 


Partly  met.  Range  does  not  define  a type,  and  the  range 

specification  is  mandatory  for  numeric  variable  (inteqer:  np.  37-58; 
real:  pp.  AA-A6;  fraction:  pp.  58-60). 

However,  there  is  no  fixed  point,  erqo  no  step  for  fixed  point. 

The  necessary  modification  is  part  of  the  work  of  adding  fixed 
point  — see  the  evaluation  of  »2. 


D5 . The  range  of  values  which  can  be  associated  with  a 
variable,  array,  or  record  component,  will  be  any  built-in 
type,  any  defined  type,  or  a contiguous  subsequence  of  any 


enumeration  type.  ....P 

Ranges  of  an  enumeration  type  are  allowed  .......F 

No  arbitrary  restrictions  on  the  structure  of  data  T 


Partly  met.  There  are  no  arbitrary  restrictions  on  the  structure 
of  data  (pp.  82-8A,  9A-95),  but  there  is  no  way  to  associate  a range 
with  a variable  of  an  enumeration  (STATUS)  type.  (p.  76). 

The  necessary  change  is  minor. 


D6.  The  lanquage  will  provide  a pointer  mechanism  which  can 
be  used  to  build  data  with  shared  and/or  recursive 
substructure.  The  pointer  property  will  only  affect  the  use 
of  variables  (including  array  and  record  components)  of  some 
data  types.  Pointer  variables  will  be  as  safe  in  their  use 


as  are  any  other  variables.  ....F 

Recursive  and  network  structures  provided  F 

Handles  variable-value  and  structure-component  connections  F 

rointer  property  is  an  attribute  of  a typed  variable  F 
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Pointer  property  not  for  constants,  affects  only  assignment  .....N/A 
Pointer  property  mandatory  for  dynamic  allocation  ........ .......F 

Allocation  scooe  never  wider  than  access  scope  U 

(Either  the  value  or  the  rointer  is  modifiable)  .................  F 

(Pointer  mechanism  handles  procedures  and  parameters)  ...........F 

(Remap  and  replace  assignment  have  different  syntaxes)  n/a 

(Built-in  dynamic  variable  creation)  T 

(Variable  equivalence  classes  are  declarable)  .F 


CS-4  has  no  pointer  mechanism  as  yet  (p.  79-80  of  Part  III). 
Indeed,  even  in  the  section  discussing  a future  pointer  capability,  the 
comment  is  made  that  recursive  data  structures  are  being  considered  as 
an  alternative.  This  shows  that  the  planning  had  not  proceeded  very 
far:  recursive  data  structures  alone  cannot  support  all  needed  pointer 
capabi l it ies  . 

If  done  right,  addition  of  a pointer  mechanism  would  be  a major 
effort,  and  would  effect  such  other  vital  features  as  parameter  passing. 

A rudimentary  pointer  mechanism  (e.g.,  similar  to  that  in  pascal) 
could  be  patched  onto  the  current  definition  with  moderate  effort. 


I| 

I 
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El.  The  user  of  the  lannuaqe  will  be  able  to  define  new  data 
tynes  and  operations  within  programs.  ..».P 

Partly  met.  New  types  can  be  defined,  but  new  operators  can  not 
(pp.  1S7-172).  New  operations  for  the  new  types  can  be  defined,  but  are 
accessible  only  via  procedure  calls. 

Necessary  changes  are  of  moderate  difficulty.  The  expression 
parcer  is  rather  strongly  affected. 


E2.  The  "use”  of  defined  types  will  be  indistinguishable 
from  built-in  types.  ....T 


Partly  met  (rp.  17,  170-17?).  Components  of  data  objects  defined 
by  the  user  are  not  accessible  directly  (see  pp.  117,  163).  The  only 
infix  operators  usable  with  a new  type  are  = and  “=  (p.  169),  tut  the 
same  is  true  of  some  built-in  types  (e.n.,  STATUS).  Assignment  can  be 
defined  for  a new  type  (pp.  163-164). 

The  necessary  change  is  of  medium  difficulty.  It  interlocks 
closely  with  the  addition  of  user-defined  operators  (FI). 


E3.  Each  proqram  component  will  be  defined  in  the  base 
language,  in  a library,  or  in  the  program.  There  will  be  no 
default  declarations.  ....T 


met.  (pp.  2,  14-16). 


F4 . The  user  will  be  able,  within  the  source  language,  to 
extend  existing  operators  to  new  data  types.  ....F 


Not  met.  Only  the  = and  -=  operators  can  be  extended  to  new  types 
(p.  164). 

Scope  of  change:  Moderate.  It  is  closely  connected  with  provision 
for  user-defined  operators  (El). 
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E 5 . Type  definitions  in  the  source  lanouage  will  permit 
definition  of  both  the  cless  of  data  objects  comprisinq  the 
type  and  the  set  of  operations  applicable  to  that  class.  A 
defined  type  will  not  automatically  inherit  the  operations  of 


the  data  with  which  it  is  represented.  ....n* 

Construction  T 

Selection  ............P 

Predicates  p* 

Tyre  conversions  .T 

Operations  and  data  can  be  defined  toqether  .....T 


Construction  is  a special  case  of  the  CS-A  concept  of 

mode- invocat i on . 

Selection  is  accomplished  by  means  of  the  standard 
dot-qualification.  For  example,  if  x is  a variable  of  a defined  type 
(mode  in  CS-A  terminology)  and  I is  a "representational  entity"  of  that 
type,  then  X.l  refers  to  the  specific  instance  of  1 contained  within  the 
"value"  of  X.  A minor  deficiency  here  is  that  all  "representational 
entities"  of  a defined  type  are  accessible  in  this  manner.  It  would 
aopear  that  the  person  who  defines  a type  might  want  to  hide  or  protect 
some  of  the  "representational  entities". 

Predicates  and  tyoe  conversions  can  be  defined  by  means  of 
procedures.  Predicates  are  not  definable  as  special  operators  (e.q., 
infix),  however  (see  FI). 

The  ability  to  declare  a "representational  entity"  to  be 
inaccessible  would  require  a fairly  minor  change  in  the  lanquaae.  To 
allow  special  operators  is  much  more  complicated  (see  El). 


E6.  The  data  objects  comprisinq  a defined  type  will  he 
definable  by  enumeration  of  their  literal  names,  as  Cartesian 
products  of  existing  types  (i.e.,  as  array  and  record 
classes),  by  discriminated  union  (i.e.,  as  the  union  of 
disicint  types)  and  as  the  power  set  of  an  enumeration  type. 
These  definitions  will  be  processed  entirely  at  compile 


time.  ....T 

Enumeration  T 

Cartesian  products  (records)  T 

Discriminated  union  T 

Powerset  of  an  enumeration  tyre  T 


r 
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Met . Enumeration  is  called  STATUS  (pp.  76-82),  Cartesian  products 
are  celled  STRUCTURES  (pp.  94-99),  discriminated  union  is  called  UNION 
(pp.  113-121),  and  powerset  is  called  SET  (pp.  253-256). 

; 


E7.  Type  definitions  by  free  union  (i.e.,  union  of 
non-disjoint  types)  and  subsetting  are  not  desired.  ....T 

Met.  The  only  unions  are  discriminated  (pp.  113-121),  and  there  is 
no  way  to  define  a type  (mode  in  CS-4  terminology)  as  a subset  of 
another. 


E8 . When  defining  a type,  the  user  will  be  able  to  specify 
the  initialization  and  finalization  procedures  for  the  type 
and  the  actions  to  be  taken  at  the  time  of  allocation  and 
deallocation  of  variables  of  that  type.  ....T 

Initialization  .........T 

Finalization  T 

Allocation  actions  T 

Deallocation  actions  ....T 

Met.  Initialization  and  allocation  operations  can  be  done  in  a 
user-defined  INIT  procedure  (pp.  165-167).  Finalization  and 
deallocation  can  be  done  in  a TERM  procedure  (p.  167). 


■ 


L 


A 
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FI.  The  language  will  allow  the  user  to  distinguish  between 
score  of  allocation  and  scope  of  access.  ....p 


Partly  met.  Allocation  and  access  scopes  can  be  different,  but 
only  if  the  allocation  scope  is  the  whole  program,  similar  to  ALGOL  60 
own  (n.  20),  or  if  the  data  object  is  shared.  In  the  following  block 
structure,  it  is  not  possible  to  have  an  object  whose  allocation  scope 
is  block  P2  and  whose  access  scope  is  *»3. 

B1:  BFGIN 
p?:  PFGIN 
P3:  PFGIN 


END;  END;  F ND 

The  change  should  be  relatively  easy.  The  AUTOMATIC  storage  class 
declaration  would  simply  have  to  carry  an  optional  parameter,  giving  the 
block  name  of  the  allocation  scope  block. 


F 2 . The  ability  to  limit  the  access  to  separately  defined 
structures  will  be  available  both  where  the  structure  is 
defined  and  where  it  is  used.  It  will  be  possible  to 
associate  new  local  names  with  separately  defined  program 


components.  ....T 

Allowable  operations  can  be  limited  T 

Access  can  be  limited  where  used T 

External  declarations  need  not  all  have  the  same  scope  T 

Naming  conflicts  can  be  avoided  (renamino)  T 


Met.  Limiting  of  allowable  operations  is  discussed  on  pp.  157-122. 
Limiting  access  to  external  entities  and  renaming  are  discussed  on 
pp.  174-176. 


F3.  The  scone  of  identifiers 
compile  time. 

Met  (pp.  14,  126-127,  140). 


recent  F 4 


f 4 - 0 variety  of  pro  l •»  c at  i on-nri  pr.tr  H data  anH  oper  at  i < ; r-s  •- 

will  b.  p available  in  libraries  a nd  e a s i l v accessible  i r ♦ b » 
l a nouaoe . 


iJrlmriKn.  T * is  i-rrlier1  (pn.  the  the  Ccfr^iler  *ill  have 

iccess  to  entities  external  to  tie  '-rtMir  ir,  he  in?  compiler,  t.j‘  it  is  no* 
stated  tbit  t*-ese  entities  -ill  be  in  libraries,  ir..t  no  tools  for 
bui  l di  n.;  such  libraries  are  drfiren. 


f rj . trnoram  exponents  not  driinee1  within  the  current 
ore  :rvrr  and  rot  in  the  bare  If  nr  or.  -e  will  be  rr  a irt  c.int*''  in 
compile  time  accessible  libraries.  the  libraries  will  be 
caralile  of  holdini  anythin:  definable  in  tfe  lanquade  ann 

will  net  exclude  rout  inr*  .host  bonier  are  written  ir  other 
source  l anmj&q  es  . ....  ! 

Program  componrnt  libraries  accessible  at  compile  time  ij 

libraries  can  contain  forc-inr  lannum?  routines  .u 

. Interface  reoui  resents  checker  l«  at  roepiin  time  . • 


unknown.  s»e  F4. 


Ft.  Lilraries  and  f^tirrols  will  fe  i nd  i st  inouish  ab  le  . They 

will  be  capable  of  hoM’n  i anyt^ino  definable  in  the 
lanuuane,  and  it  will  ►»  rnssil.  If  to  associate  ther-  with  any 
l»vel  of  pronrarrni  no  activity  f roe  svstens  throuoh  rroincts 
to  individual  prnnrams.  There  will  he  many  specialized 
conools  or  libraries  any  urer  srecified  *ubset  <f  which  is 
i mmeui  ate  l y accessible  from  s ,’iv'>n  nrooram. 

libraries  and  comp  no  Is  will  be  i nd i s t imu i sh "»b l e r 

Immediately  accessible  sublibraries  a*  ar>y  leyp)  ............... .ii 


tin  known.  f“e  F4. 


Y 
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F7.  The  snurrp  Unmirfrc  toil  l cortain  standard  machine 
in'>(  rodent  interface?  to  f der'.-rdent  c i l i t i , 

including  , rrii  her*l  ecuiimtrt  ard  srecial  hardware.  ....t 


"nt  r.?t.  Tk,»  f s - 4 “r,»r?fin'  Svsfp-  ’nterf’Ce  or  ovides  til* 

K?nd|in~  and  parallel  rrocesrih',  tut  these  *re  covered  by  r . r:u  i remen*  s 
”1i  f.r J c-f  , n't  tvis  men  ire  rent.  There  are  no  provisions  frr  each  in* 


i n^epens  *r  f interfaces  to 
h a r J » <•  rt . 

rrerific 

neri^h^ral 

er  pi  ''Tent 

nr  ?oeci*l 

v ••  e t i n '»  the  r "-iji  ro"ert 
im.ilefl.rrtatior  e lfcr*-#  and 

« r> i.’  1 r 

i n » e d , 
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Vr  “ are  rot 

s r e j or 

sure  hpi.,  on* 

’esitin  -»ru. 
Should  ; o 
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Cl.  T ► c lancuaoe  will  provide  rt  ruct'.ren  control  mechanisms 
♦ or  seuuenti  il,  ccndit  ion? I , it“rativr,  and  recursive 
rcntrul.  It  will  also  provide  control  structures  ♦or 

(nseudoi  parallel  procession,  eycertion  hardline,  i;no 

async hrorous  interrupt  nandlion. 

f equent  i a l execution  r 

Conditional  execution  .1 

Iteration  T 

Recursion  I 

(Fseuae. ) parallel  processiro  T 

Excerticn  handlist*  ...............T 

Asynchronous  interrurt  hardline  ................................ .1) 

Ccrtrcl  structures  from  a small  set  of  simple  primitives  ........F 

Not  tullv  re  t:  C S-4  ^as  recursive  procedures  as  v^t 

♦rp.  17«“140).  f?-4  does  trv"  interrupt  hindlirc,  by  means  of 

SI  GNA  l -.mod  l i no  procedures  f pr  . 

The  set  ut  primitive  control  structures  is  laraer  and  more 

complicated  than  necessary.  r*lt  and  «»<’9T  TC  ere  simply  euphemisms  fur 
coin,  hence  are  superfluous.  worse,  tor  r=»rallel  processine  there  are 
rinr  scheduling  procedures,  ‘our  sy  rich  roni  r i nn  ones,  six  ivraiieters 
describino  priority,  and  einVit  process  states.  (Part  11,  no.  21-i4). 
Tnis  hardly  seems  a small  set,  cr  a primitive  one. 

Scope  of  chance:  *?jor.  Recursive  rrocedures  are  never  easy  to 
add,  and  tney  effect  much  else,  particularly  in  imp lementation.  In  our 
view,  no  one  has  yet  designed  a oood  set  of  par’llel  processing 
capabilities  for  « larouaye  — the  problem  must  be  hard. 


(2.  The  source  lanouare  . i l l provide  a ”r0  TO"  operation 
applicable  to  program  label.'  within  its  most  local  score  of 
definition.  ....■’ 

Fartly  met.  The  f$-4  CiCTO  can  transfer  control  out  of  a score 
level,  although  not  into  a scope  or  rut  of  a procedure  (po.  1J5-T3 ft). 

'-'e  regard  the  AthRT  TO  statement  as  only  a syntactically 
camouflaged  GOTO,  and  it  leads  out  of  an  exception  handling  nroreiure 
fr.  1 3 •» ) . 


cope  of  chare**:  Relatively  miner. 
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63  . The  ccrdi t iont l control  structures  will  be  fully 
c e r t i t i cn*  .1  -«Tid  «'i  I l permit  s^lec^ion  a"onn  a 1 t e r nat  i vCT 
c omnpt  a*  i ons  h’Sf  1 or  the  value  rt  a boolean  expression,  on 
th®  subtyoe  of  a valje  from  a discriminated  union,  or  on  a 
compute”1  choice  ampna  labeled  alternatives. 

* a sen  cr  Hooler,n  expression  1 

on  tvpe  Iron  biscrim  irat"'1  irirc  ...I 

Ha  sea  on  coTrute  1 thrice  errorr  labeled  alternatives  T 

#11  rlternativ'’  rust  be  am  counted  for  T 

Simpl*  mechanisms  will  I e sup’,  lied  for  common  cases  .............  T 

"ft  r rp  . 1>?-I3f).  Tull  di  s c r i tr  i na  t i on  for  ?n  it  is  vruvided  b> 
the  closim  r I . The  ir  is  a simple  snecial-case  irrchanisi',  and  it  need 
not  have  on  r L S F . 


u4  . fh<»  iterative  control  structure  will  remit  the 
termination  condition  to  a;*ear  anywhere  in  the  loon,  will 
require  comtrcl  variables  to  be  local  to  the  iterative 
control,  will  allow  ertrv  on  ly  r,  t t^c  head  ct  the  loop,  ?rH 
will  nrt  impose  excessive  overhead  i*-  clarity  np  r*jn  the 
exception  costs  for  common  special  case  termination 
conditions  (e.">.,  tired  number  of  iterations  or  elements  of 
an  array  exhausted).  . ...i  + 

Termination  car  occur  anywhere  in  the  loor  ......................  T 

Multiple  termination  rreaic?t*>s  are  possible  ....................  I 

Frtry  permitted  only  at  the  Iron  bead  T 

Simple  cases  are  clear  .and  efficient  ot 

Control  variable  is  local  to  the  loop  T 

Control  value  is  efficiently  available  after  termination  F 

Partly  met.  The  CS-4  iteration  statement  (PEF’Fat,  optionally 
preceded  by  WHILE  »nfl/r.r  FOP)  is  fairly  clean  and  efficient,  and  meets 
the  requirement  except: 

(1)  There  is  no  clear,  mechanism  for  the  very  common  "n  and  a hnlf" 
times  loop.  (n  FMT,  tantamount  to  p GOTO,  must  he  used: 

L:  KFI’FAT 

(net  data); 

It  (exhausted) 

THEN  T xi T L 

ELSE  (process  data)  FI; 

F M D 


CS-4 
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" . J . right's  syntax  avoids  the  F X I T : 

loop 

{rj?f  data) 

while  (rot  exhausted)  : {process  data) 

repeat 

(t)  (.S-A  has  ro  means  of  makinc  the  value  of  the  control  variable 
accessible  after  termination  of  the  loop,  except  hy  assi  min:;  it  to  a 
variable  not  local  tc  the  Icoc  on  each  iteration,  and  this  is  hardly  the 
most  “fficient  wav.  Coo.  13?-134). 

rifficulty  of  chanae:  easy  to  mourn  rate  . 


Gi>.  Recursive  as  well  as  nonrecursive  routines  will  he 
available  in  tKe  source  lannuaoe.  It  will  net  he  nossible  to 
defire  rrocedures  wit  l;  in  the  body  of  a recursive 
prnordure.  . . . . F 

No  recursive  procedures  within  recursive  procedures  F 

(maximum  depth  of  recursion  car*  he  specified)  ...................  F 

(Recursiveness  must  be  specified)  F 

Not  met.  (S-A  h«  rt  recursive  rrocedures  — a maior  lack. 
<r  o . 13‘>-Ku>. 

Scod'  of  channe:  ,'iior. 


G6.  The  source  lan^ua’ae  will  orovidf  f parallel  processino 
caroLlitj.  This  capa$HPity  should  inrluce  the  ability  tc 
create  and  terminate  dpossit.  le  nseudo)  parallel  nrncesses  and 
for  th“se  processes  to  nain  exclusive  use  of  resources  duriru 
specified  portions  of  „their  execution.  ....p 

• hi**  to  create  and  termina  t e ’ - ars  1 1 e l processes  .........T 

Process  can  aain  exclusive  use  o4  resources  .....T 

No  parallel  routines  within  recursive  routines  T 

No  rcuMn«*x  within  rarallel  rcjtinef  ............................  f 

Naximur  number  c>f  simultaneous  instances  are  declarable  .........F 

(Access  rules  « re  er force'*)  - T 


c* 

w “Ti»i  r e nt  C* 


Part ly  met . 

A (f-rallel  procedure  in  ( S-4  is  not  i dp  nt  i t i ed  af  such,  aM  -nay 
r r c sii»et  l y also  be  ealle'4  in-line,  ever  recursively.  There  is  no  wav  ►n 
specify  the  in  a gi  mum  permissible  ro'her  of  s i^ul  tf^rcus  instance  of  a 
parallel  r recess . 

Tt  is  re*  dear  when  the  ' i rasrf"r'  of  a parallel  process  are 
heync*;  rreju’aMv  when  H»  rr;  cess  is  s rhedu l ed . It  is  evidently  not 
nrssihle  *o  defire  a parallel  procedure  vithi,">  ♦’he  body  of  3 rerursiv1 
or  a tarallel  crccedure  (fart  TI,  p.  r?4) 


Tr.p  CS-A  parallel  nrorersin  car eb i I i ty , in  short,  while  in  lur 
oninico  far  too  compt  i cated , s^^isfip*-  the  CYi  reouirement  except  that 
the  maximum  number  of  s imu  1 1;  necii*  activations  is  nor  dec  larat.  le. 

nn  l y minor  chanr*  i «:  needed. 

The  capability  is  in  direct  ccrtlic*-,  bowtver,  with  requirement  >'T; 
an  me  rati  no  svst»,r  ir  renuired.  for  eysirrle,  deacline  schedulin’! 
irnlier.  that  the  CS-4  scheduling  mechanism  has  control  of  the  entire 
machine.  The  capabilities  are  ever,  described  under  the  heading 
"Of  pratin'-’  System  Interface". 

hcr.f  l i cts  , S r npp 


07 . The  exception  handling  control  structure  will  permit  the 
user  to  cause  trarsfer  of  control  and  data  for  ary  error  or 
fxcpftion  situation  which  nidht  occur  in  a rroorom.  ....ft 

fre  ’ram  can  oet  control  fer  any  exception  .....I 

Parameters  can  be  passed  P 

Pan  /et  nut  of  any  level  c * a nest  of  contr«;'l  T 

Can  handle  the  exception  at  arv  level  nf  control  T 


Partly  met. 

txceotions  caused  by  "cberlino  directives"  (e.o.,  zero  divide^ 
carry  no  arnurrents  ((  . 1 7t>. 

to  yrt  out  of  af.y  arbitrary  ''est  of  rontrol,  an  "*PORT  T(>  l sue l" 
statement  is  used  (r.  1?r).  This  i*  in  effect  a GOTC  cut  of  ? 
procedure,  hut  an  unavoidable  <>n».  The  advantage  of  usino  APORT  TP 
rather  than  GOTO  i?  not  clear. 


Relatively  minor  charoe  re cc*rary 
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Gf . There  bill  be  source  l anouaoe  features  which  permit 
del.’y  on  any  control  path  until  some  specified  time  or 
situation  Has  recurred,  which  permit  specification  of  the 
relative  priorities  among  parallel  control  paths,  which  give 
access  to  real  time  clocks,  j* i ch  permit  f synchronous 
hardware  interrupts  to  le  treated  as  any  other  exception 
situation.  ....l’+ 

Priority  specification  T 

Synchronization  via  wait/enable  operations  .T 

wait  for  end  of  real  time  interval  .....T 

• ait  frr  erd  of  simulated  time  interval  .........................  F 

l ait  fnp  hardware  interruft  T 

(Can  enable  and  disable  interrupts)  ..( 

Kot  fully  met.  There  is  apparently  no  concert  of  simulated  time  in 
CS-4 . The  TimE-wAIT  procedure  (Part  II,  p.  67)  *vident l y causes  a wait 
in  real-time  only.  See  also  Part  II,  pp.  21-3?,  63-67. 


"ircr  chance  necessary 
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Hi.  The  source  li-nauacjfc  v/  ■»  l L be  free  format  with  ar.  explicit 
statement  delimiter,  will  <.  I l r w t r e use  of  mnemonirally 
significant  identifiers,  will  be  bases  or  conventional  ftrms, 
will  rave  a simple  uniform  and  easily  parsed  grammar,  will 
net  provide  unique  notations  for  special  cases,  will  not 
remit  abbreviation  cf  identifiers  or  key  words,  and  will  be 


syntactical ly  unambiguous.  . ...M- 

Free  f or rre t with  statement  terminator  ...-  .T 

mnenonic  identifiers  possible  ........I 

fared  on  convert  ions  l terms  . ^ 

Simple  or  pm  mar  f 

\o  s'eci'l  case  notations  r 

Vo  abbreviations  of  identifiers  or  keywords  ................... ..T 

Unnn.b  i iuous  grammar  ............T 


Only  partly  "®t. 

The  svnta*  of  CS-4  is  net  on«*  of  its  better  features.  It  aces  m-et 
cart  of  the  requirement:  If  is  free  format  »itb  a statement  terminator, 
it  allots  inentifiers  to  bn  ur  to  charact*r<;  lom,  the  grammar  is  (ti 
our  knowledge)  formally  unamh.  i < uous , ant)  there  is  almost  no  abbreviation 
of  worns  (exceptions  are  i fnr  a \ P , | for  or#  and  ~ * or  vot  ) . 

However,  the  lanauaoe  is  nr  t eesy  to  rear.  ATI'<  is  used  t 

introduce  attributes  cf  either  formal  ^aramc-ters  or  of  the  whole 
procedure,  so  that  parenthesis  countin’  is  often  necessary  tc  sirt 

thinos  out.  The  array  declaration  is  very  hard  to  mad;  for  example: 

ARRAYfl  Thfu  ?,  I V T F fi  l R (PAf.0F:1  THRU  10>  f CEIL  CX)J  HPU  2)1, 

REAL  (RANGF:  f)  THC"  ICOnf),  F'RFfISIOM:  IP)) 

Not  until  *1*  is  reached  is  it  clear  that  the  INTFGFi;  is  a call  on  » 
conversion  routine,  net  the  tvp'*  of  t *- e array  renters.  It  would  t-:yn 
been  much  better  tc  separate  tf  **  types  of  the  subscripts  erri  the 

Tempers  . 

Similarly,  the  maraatrry  r^noe  sme  i t i cat  i ons  on  nor  ♦ ty-e 

conversion  calls  make  them  often  all  but  uor e -oani znt  l e ; see  *nr  ex  mole 
the  conversion  on  rage  14'^  of  the  rs-4  y.nual  — it  t»k“*  11  lines!  The 
worst  example  of  such  wordy,  over-c  ,;.ternal  irti  r syritax  is  the  fopttin* 
dec larotion;  this  example  appears  on  ra^e  1ft: 

TONiSTANT  TWO  IF  I N T c 0 F R f°A'GF:  ? THRU  ? > [ ? 1 

why  not 

const  A ‘I  t two  = ? 

or. 


if  recessary 
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1 NT  l 6 F R CONSTANT  T*0  = ? 

hprce  we  believe  that  while  the  rs-4  syntax  nay  he  *or  m<i  1 1 1 v 
jnamoi  cjnus , it  can  se  very  hard  for  a human  to  read. 

Mrrecver,  the  rule  tor  blanks  is  very  dangerous.  Spaces  nay  be 
inserted  or  omitted  at  will  excert  where  arbi cutty  arises.  por  example, 
ROTOll  is  presumably  acceptable  unless  there  is  also  a procedure  name.] 
5OT0L1  . Amon-!  other  thinrs,  this  mikes  it  danoerous  to  add  n 
identifiers  to  an  existino  '-rcor^m. 

(The  manual  is  not  wholly  clear  on  this  matter  ot  spaces,  ''sim  i 
different  i nterr retat ion  of  the  rnrase  "valid  token"  on  page  v , one 
could  say  that  fiOTOLl  is  nr t allowed,  tot  in  that  case  neither  is 
SOTO  — only  SO  TO  --  which  has  its  own  problems  ). 

Nor  can  the  syntax  he  regarded  as  simple:  There  are  some  ?!>S  syntax 
definitions.  The  initial  definition  of  PASCAL,  ty  contrast,  has  less 
than  1 ['  3;  ALGOL  hn  (^eviserl  Report  T , less  than  1 ?S . It  is  not  clear 
whether  the  extra  complexity  of  CP-4  is  in  the  language  or  the  syntax 
definitions;  either  wav,  there  i*-  a problem.  The  C5-4  syntax  is  also 
complex  enough  to  still  contain  rathrr  basic  errors;  for  example,  it 
allows  a orocedur®  to  be  a component  of  -n  array  or  structure.  (see 
op.  ?r-,  '/A).  This  is  clearly  a mistake,  because  there  is  no  wav  to 
reference  such  a procedure. 

Tie  syntax  is  also  not  wholly  consistent.  Procedure  parameters  ire 
encloseo  in  parentheses  except  for  cb je rt-const ruct ion  procedures,  where 
square  brackets  f re  used.  The  CEIL,  FI. 00°,  and  ROUNh  conversion 
procedures  are  syntactically  different  from,  other  conversion  procedures. 

Scope  of  charge:  ""aie.r.  ' redesign  of  many  of  the  most  complpx 
parts  c4  the  syntax  ir  necessary,  and  a clean  syntax  is  not  easy  to 
design  . 


H?.  Thp  user  will  not  te  able  to  modify  the  source  langur'"* 
syntax.  Specifically,  he  will  not  te  able  to  modify  operator 
hierarchies,  introduce  new  rrece derce  rules,  define  new  key 
wor*  forms  or  define  new  infix  operator  precedence*:. 


..  ! 


vet.  The  lanpuane  includes  no 
chaneiro  nr  addin'-  to  the  syntax. 


cr'-  facilities,  and  no  *onls  tor 
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Hj.  The  syntax  of  source  l»n:iuT*e  nroprarrs  will  he 
c onto  sable  from  a character  set  suitable  for  publication 
ou r *'c.s * s , hut  ro  feature  of  lanquane  will  be  inaccessible 

jsio..  the  64  character  ASCII  subset. 


This  requirement  is  rot  net.  CS-4  uses  c4  rrintinu  characters,  in 
addition  to  tie  ntw-line  sequence  and  the  tlar.k  (p.  r’). 

This  requires  orly  a relatively  minor  ct  snie . the  only  chiracters 
not  in  thr  s S C 1 1 subset  are  the  lower  cane  letters,  f,  ),  ar.d  ” . 


t-4.  The  lenouaqe  definition  ^ill  provide  the  formation  rules 
for  identifiers  and  literals.  The<-,e  will  include  liter  Is 
for  numbers  and  character  strings  and  a break  character  for 
us®  internal  to  identifiers  and  literals. 

Bre.k  character  exists  

(Literals  are  se  l t-ider.t  i f y i r~  as  to  *yre)  

(Pit-strinn  literals  for  ary  tyre)  


Tt  is  requirement  is  partly  met  (rp.  6-1P).  There  is  a break 
character  (underscore)  for  identifiers,  but  not  for  literals.  Literals 
for  numbers  and  character  strings  are  provided. 

#ry  necessary  charge  would-  tp  minor. 


m5p  Tb»re  will  be  nc  continuation  of  lexical  units  acm«-)S 
lin^s,  but  there  wilt  op  a way  to  ircluoe  ot'iect  characters 
suen  as  end-of-lire  in  literal  string.  ....f 

This  r°quirement  is  not  met.  The  new-line  sentience  is  treated  as  a 
sr*ce,  which  cannot  appear  in  strim  and  status  literals,  but  which 
apparently  is  iuncred  in  identifiers  it  no  amhinuity  •’rises  ( up . V-10). 

«nv  necessary  change  would  be  minor. 


H6.  it»y  words  wilt  be  reserved,  -ill  be  very  tew  in  numtur, 
vi  U h e inf  ur»-  >t  ive  , and  * i l l rot  l e us=>l  l"  i r.  contexts  where 


c s -<• 

R^jji  rP'ont  >*6 


Vj 


an  identifier  can  be  used. 


1 - i s re^jirrTent  is  partly  Tat.  In  total,  thtre  ere  st>7  key  war  ds. 


of  » *■:  i c *i  V 
(pc.  ?M-?h3) 


are  fully  reserved.  this  seem*-  more  than 


f 


1';  *-pduce  tie  rubber  cf  kay*ords  won  Id  tip  ? ',)irlv  difficult 
change,  as  j syntax  rede  He-, n .ctild  be  required . 


H7.  The  source  lannuare  will  have  a single  uniform  connent 
convention.  Comments  will  te  easily  distinguishable  from 
ccr.p,  -’ill  be  introduced  by  a sin'l“  (or  possibly  t*--) 
language  defined  characters,  will  permit  any  comtinaticn  cf 
characters  to  appear,  will  re  able  to  appear  anywhere 
reasonable  in  rmrams,  will  autonot  i ca  l ly  terminate  at 


end-of-line  if  nr*  otherwise  terminated,  and  will  not 
prohibit  automatic  reformatting  of  nrmramr. . . . . . T 

bni'crm  comment  convention  ....T 

Look  different  frc*  code  . . 1 

crocheted  by  one  or  two  character*  ..............................  I 

Ca>-  contain  a ro,  cbfroftf  rs  ..............................T 

fan  appear  anywhere  reasor.ahte  T 

Terminated  by  th*  end  of  the  line  ...T 

fomj&tible  witr  automatic  refr  rrattin  T 


This  requirement  is  fullv  met.  (m. 


Hh.  Tte  language  wifi  rot  permit  unmatched  parentheses  of 
any  hind.  ,...T 


tpis  requirement  is  fully  met;  see  the  syntax  ^ercr  intion 
<PP.  ?Tv-?3a). 


h-J.  There  will  be  a uniform  referent  notation. 


rs-4 
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This  requirairpnt  is  partly  not;  see  the  syntax 
(ry.  ?*_<>  — ?3fs>  . rails  or.  cbiec*  construction  procedures 
’T'-uTf rt  brackets;  all  others  use  parentheses. 

The  scone  of  anv  reauire-  cbanae  is  minor. 


HI  r, . Mo  language  defined  symbols  anpearina  in  the 
context  will  Have  essentially  different  meaninos. 

this  reouireTent  is  fully  met-  Verification  recuires 
the  entire  language  manual. 


I 

j 


dose  r iotior 
use  square 


same 

T 

a study  of 


CS-4 

^equi reirent  11 


3 2 


11.  There  Mill  he  no  default?  in  programs  which  affect  the 
program  loaic.  That  is,  excisions  which  affect  program  lioic 
will  be  made  either  irrevocably  whep  the  lanauaoe  is  defined 
or  explicitly  in  each  nrooram.  ....P 


This  requirement  is  partly  met.  The  precision  for  floatino  point 
arithmetic  is  not  specifiable,  and  it  is  implementation  dependent 
(pp.  71,  204) 

Only  a fairly  minor  chanqe  would  be  required  tc  specify  floatino 
point  precision. 


12.  Defaults  wilt  be  provided  for  special  capabilities 
affectinn  only  object  representation  and  other  properties 
which  the  proorammer  does  not  know  or  care  about.  Such 
defaults  will  always  mean  that  the  i roorammer  dees  not  care 
which  choice  is  made.  The  proorammer  will  he  able  to 


override  these  defaults  when  necessary.  ....P+ 

Defaults  specified  for  don't  care  cases  ......................... P 

Programmer  can  override  the  defaults  T 


This  requirement  is  partly  met.  The  comniler  supplies  defaults  for 
standard  procedures  (ASSIGN,  COMPARE,  1NIT,  and  TERM),  for  user-op f iner; 
types,  for  procedure  calls  (CLOSTD),  for  storaoe  class  (AUTOMATIC),  and 
for  checking  cateoories  (ENAPLFD);  these  can  be  overridden  (p . ?V;). 
Only  for  MSTRUCTUPFS  (pp.  169-193)  must  data  representat ion  be 
specified.  However,  not  hi  nr,  is  said  about  reentrant  code. 

A minor  chance  is  needed. 


13.  The  user  will  be  able  to  associate  compile  time 
variables  with  rronram?.  There  will  include  variables  which 
specify  the  object  computer  mcoel  and  other  aspects  of  the 
object  machine  conf iouraticn.  ....T 


This  requirement  is  met.  while  there  are  only  a few  built-in 
comp i l w-ti me  "variables"  describinr  the  machine  configuration  (s.n., 
*AX_WACHINE_INTCGFR_VALUE , r.  204),  it  is  possible  to  r»1erence 
externally  defined  variables,  which  may  have  initial  valjes 
(cp.  176-177). 


i • r u i r r r f»  n t I < 


14.  T h p sourer-  l anruar*  will  rro.it  rhp  use  of  crn-fitirnal 

staf  e T-mts  fo.o.,  case  statements)  dependent  op  the  object 
ppvirrn«'ent  and  other  coofilo  ♦ i •?  e variables.  In  swch  c^es 
the  conditional  will  be  evaluated  -it  conrile  time  and  only 
t h ( r.f  lectea  .ill  ‘•p  ceri  ilen.  . . . . » 


II  is  reuuirrTent  i s not  «■  pt;  rs-/.  hr  c no  cjch  caraMlitv. 

the  change  would  t p of  src.ll  to  mon-rete  difficulty,  to  - end  i pi  on 
tne  rirrep  of  ioteorttiop  r + t h p re*  car-ability  with  cxistin  t ones. 


! 

| 


; 


IZ.  Tie  source  lanouarf  »■  i ( l 
i d e r t i f l n b l e t.  a s r nr  h e r n p l which 
lao,,uar-e.  T ^ the  e»teot  r-r,ssil  l® 


» i t h e a c t feature 
otherwise  Cun  Meat  ec 
will  o o t d e t r a c t 

unoerstardebility  o * 


(■rrvi'Mrc  a 
in  the  tnse. 

f r r n t h p 
ftp  loruLPop 


contain  a simple  clearly 
houses  all  the  newer  of  t*-e 
, t h p hare  ,ill  l«  m i n i o l 
sir. ole  uncue  capability  •'Ot 
The  choice  of  the  t>ase 
efficiency,  safety,  or 


Tkis  reoui  rpfPrt  is  not  nft.  The  built-ir  feature*-  ir.nVe  CS-4 
probably  twice  as  cootie*  as  P*5fAL,  for  example. 

Tc  restructure  CS-4  as  a s*’cll  kerrrl,  with  rest  currently  built-in 
features  crovider  ns  extensicr,  would  r e a 'raior  effort,  an  f "ii.ht  even 
chanue  the  larowar.e. 


— — 

1*.  L anon  are  restrirtions  whic>  ar°  i-'fnendert  only  cn  thp 
trarsl;,tor  an-*  rot  or  the  obiect  « jchior  will  ne  srecifi“d 
pxi  licitly  in  the  larouaoe  definition.  ...,T 


T ‘ : i r.  rpauire'pot  is  rot  m»t  . 


To  ctarujp  fa  - 4 tc  meet  it  would  he  fairly  easy,  but  oon-friei’l 


es-4  u 

Requirement  17 


17.  Lennuaqe  restrictions  which  are  inherently  dependent 
cnl>  on  the  object  environment  will  not  te  built  into  the 
lan-’iiaoe  definition  or  any  translator.  ....T 

This  requirement  is  iret,  except  that  it  is  unknown  whether  the 
translator  will  aive  a warnino  it  object  machine  capabilities  are 
exceeded. 


jl.  Irt  l»p’iif':e  fir-1  its  tr;r  slrtcr'  ..ill  net  itrpcsc*  fun 
tie*  co'ts  frr  ur.needed  or  mused  qene  r a l ■>  t y . Ihev  /ill  ’p 

c?'  -t  l'  of  i.roiucinj  efficient  crrt  for  all  rrcornfs. 

No  efficiency  co't  frr  unused  feature*  ...................... 

Efficient  coHe  cap  be  rrHucn1  frr  /II  features  ............. 


T*  is  re 'ui revert  is  r ar  * l y "ft.  ie  think  th<t  ef  f icien*  core  *rr 
collir1.  f«rpr»i«r-h,ipflir'-  rref ’^urf  s ..ill  rot  be  possible  — it  ij  not 

clear  .!  v the  pertinent  . r re «*  in r •'  is  determined  bv  a dynamic  r«  l l -chain 
search.  .’e  at-'  stis;  net  that  •.  rovi^i'c  t *.r  At  OR  1 TO  statnertr.  «*  i I l 
introduce  overhead  not  otherwise  necessary,  r e rt i cu t a r l v when  recirsive 
~ r nc  e rlu  r e s ore  added.  ^e  note  that  the  manual  dees  not  define  whether 
C JPYC  or.  raeeterr  ( i . 144)  are  s « T or>  ’r  AhaPT  t,i  exit.  Tie  only 
opt  i mi  7<  t i or  directive  is.  * OKFCAIL  fri  . 14?,  ISO);  '•*rfcinty  others  will 
re  npecen  ♦ ' r really  efficient  cone  (e.c.,  tot c i f i ca t i cr  o * 
recursiveness,  arid  of  the  mayirur  depth  of  recursion). 

If  is  hnrd  to  pin  d^wn  tht  scoop  of  any  r.pcessary  rhan-e  in  the 
absence  o*  existing  translators,  hut  it  rrooaMy  is  not  minor. 


J? . fin y optimisations  jerforred  by  t*"?  translator  will  not 
chcin  e the  effect  of  the  t ronrar.  ....< 


bnhnr»wn.  This  is  n translator,  rot  a lanouaqe,  requin  "eo*  , ind 
moreover  the  rrp.nino  of  "ch.nrqe  thp  effect"  is  itself  undefined.  In 
nther  wc.rJs,  the  repuirerrnt  cannot  tie  evaluated  for  any  lariouan0,  even 
if  it  *rre  restoted  »itn  reasonable  nrecisicn. 


JZ.  1^®  source  lannunre  sill  provide  encapsulated  access  t i 
machine  dependent  hardware  facilities  inrludinn  "achin' 
lanoijpoe  code  insertions.  ...,T 

This  r<  • ui  r rmc  nt  is  4u  l l y met  f nf  . 1 c'o-l  • • ) . 


J4.  It  will  le  fossible  eit^ir  t^e  'onrce  lonuaqe  to 
srerifv  th«  r b ; e c t 'resent a tirn  of  cn-po s i * e nata  structure?. 
Tte/j.  description*-  will  he  r(  ft  oral  on-<  encapsulated  ?ni  wilt 


CS-4 

Reouirrment  J4 


be  distinct  from  the  Incieal  description.  The  user  will  te 
able  to  specify  the  time/space  trade-off  to  the  translator. 

If  not  specified,  the  object  representation  will  be  optimal 
as  cetermiried  hy  the  translator.  ,...P- 

Encapsnlated  specification  of  representation  possible  ........... •-> 

Spaee/time  tradeoff  can  be  sfecified  f 

This  requirement  is  partly  *et.  The  capability  is  provided  only 
for  records  (not,  for  example,  for  arrays  as  in  «LTSS)  (rn.  I^C-I 75). 
furthermore,  only  certain  thinos  about  nappinq  can  be  srecififcu;  it 
takes  ? full  l ef t -hand-s ide  function  capability  to  handle  all  cases. 
There  is  no  way  to  specify  various  densities  of  r-acMno  for  structures. 

> moderate  chanoe  is  required,  deoencinu  on  the  power  of  the  final 
■mechanism . 


J5.  The  procrammer  will  be  able  to  specify  whether  calls  on 
a routine  are  to  have  an  open  or  closed  imr lementat ion . An 
open  iftd  a closed  routine  of  th»  same  description  will  hive 
identical  semantics. 


Ooen/closed  oroperties  can  be  srecified  

Open  and  closed  versions  have  the  same  semantics 


This  requirement  is  fully  met  <p.  14h). 


Fxtranepu?  features 


«e  rtcnT,m»ni  that  the  fc:  l loving  +eatures  of  CC-A,  nc-t-  r»*anrei  t y 
the  Tinn£r,  he  ke*t: 

* COMPLFX  tyre  and  oreratiens. 

* STRIhf  tyre  fassi.rinc  that  thp  Tinmen  r<-auires  onlv 
character  type,  not  a character  strip'’  type). 

* Trait  inquiry  pro cr^ur^s. 

* various  exj  licit  corversion* : String  to  ^oolr^n, 
status  to  or  from  inneoer,  strino  to  integer,  string 
to  status. 

* R«al  relational  procedures,  whirt  perform  the 

romr arisen  to  a specifieo.  precision. 

* Various  procedures:  Arc,  W,  SORT,  logarithmic, 

exponential,  and  trigonometric  procedures,  SUCC  and 
PR  tD. 

* ^ixed-mrde  arithmetic. 

* COPYI,  ff)PY5  parameter  classes  Tea  l l hy  value  and 
result,  respectively). 


*c  recommend  that  the  fcllcwinn  features  of  rs-4,  not  required  hy 
the  T i r.n  n,  hp  deletrd: 

* VFCTOR  and  " 5 T IM  Y tvres  and  operations. 

* Cross  sections  of  a r r a v s . 

* keyword  parameters. 

* Fractior  tyre. 

* Authorities  for  u«e  of  features. 

* Ixtra  Boolean  operators:  t'ANh,  NOR,  T*p,  and  rov. 

* parameters. 


The  features 
additional  power 


reconrendeo  for 
Ce.g.,  a user 


deletion  provide  only  convenience,  not 


can  define  his  Pi,r,  vatkix  tvp 


i l DP  it 


without  beinq  ?M«  to  t-Sf  infix  operators  for 
extra  convenience  is  not  *nr*'  the  p*» ra 
etc.,  in  fhe  cases  noted. 


it).  In  our  julimr*,  »hr 
c^Tlexity,  corril' r si*e. 


CS-A  3b 

EXTRANEOUS  FFATURTS 


ro^PLFX  type  is  an  except  ion;  althcinh  it  too  could  be  defined  bv  a 
jser,  it  is  a numeric  tyoe  and  the  ability  to  use  infix  operators  is 
overriding.  If,  however,  CS-A  is  extended  to  permit  the  extension  of 
ojilt-in  operators  to  nex  data  types,  then  CO^FIFX  type  could  be 
reasonably  excluded  from  the  base  lannuane. 


rs-4 


TO 


Summary 

r «■-/,  is  a curious  lamuaoe.  If  many  important  respects,  it 
confor'ir  to  the  spirit  ct  t^e  Tinman,  and  contains  ra ny  features  which 
nave  recently  become  fashionable.  Ir  particular,  it  has: 

* Strorv;  type-checkin:?,  with  few  implicit  conversions. 

« ''nverful  data  structurin'?  tools,  -nth  full  safely. 

* ability  to  '‘tfine  new  *r*tr?ct  types  (althiuoh  not  re* 
infix  o( erators ) . 

* Support  for  parallel  ( rncessino  ar.ri  excertinn  rontrrl. 

* User  control  over  precision  and  ranoe  of  variable 
v» l ues  . 

* Complexity  occurring  "ostly  at  compile  time  (i.c., 
efficient  cndp  should  he  possible  in  most  cases). 

* Reasonally  structured  control  mechanisms  (although  it 
is  not  outstanding  in  this  ares). 

Tt  also  includes  most  of  the  features  necessary  for  systems  r roc:  r a tti  i no . 
For  example: 

* Variabl"  initialization. 

* Attention  tr  sennratt  compilation. 

* User  control  ever  rctrino  of  (some)  structures  into 
physical  store. 

* Access  to  assembly  lanujaqe  code. 

In  addition,  the  larouaoe  has  fairly  ccod  basic  consistency.  For 
ex  amp l e : 

* A function  can  return  a structure  as  its  result. 

* Expressions  are  acceptable  in  place  of  variable?  or 
constants  in  most  rmtexts. 

» Arbitrary  restrictions  are  rare. 

Cr»  the  other  side,  CF-4  vculo  require  rr.iior  change  to  satisfy  the 
Tinman  in  the  followin'*  important  areas: 

* Procedure  parameter  classes;  variable  number  of 
parameter s . 


cs-/, 
surr  a y 


4M 


* n»neric  procedures. 

* Pointers  <fS-4  has  none'). 

* Recursive  t rocedurcs  (fS-4  has  none). 

* machine  indeoendent  interfaces  to  hardware  components. 


)f  these,  recursive  procedures  and  pointers  are  the  most  important. 
They  are  basic  features  which  have  tong  been  in  scrre  languages,  and 
which  affect  (or  should  affect)  many  ether  vital  features.  It  is  rot  so 
clear  that  oroceriure  parameters,  generic  procedures,  and  machine 
independent  interfaces  to  hardware  can  be  provided  in  any  language  in  a 
.*?y  consistent  with  the  sririt  ct  the  Tinran,  yet  efficient  end  clean. 

moreover,  many  of  the  more  modern  features  have  been  included  in 
what  we  can  only  reaard  as  a pedestrian,  otter,  clumsy,  way.  This  is 
clearly  shown  by  the  overall  awkwardness  of  the  CS-4  syntax  (r.re  the 
comments  on  requirement  Hi),  the  complexity  of  the  parallel  orrc«*ssin] 
features,  and  the  wordiness  of  declarations  of  new  data  types  (even 
though  new  operators  cannot  yet  be  declared).  CS-4  is  also  a large 
lannuaqe,  far  from  sim;  le,  as  is  clearly  shown  by  the  nutiLer  of  syntax 
definitions  — and  the  syntax  appears  to  be  rather  carefully  written. 
Certain  features  seem  unnecessary;  for  example,  the  fraction  type 
(floating  point  provides  as  much  or  nor»,  in  most  cases),  the  six 
calling  modes  for  procedure  parameters,  the  svstem  of  authorities  to 
permit  a pr ooramme r to  use  certain  l a r.  q u ;•  o e features  (the  compiler  could 
instead  easily  print  what  he  did  use,  for  perusal  by  his  manager  if 
necessary).  Another  important  missinn  capability  is  a system  of 
assertions  to  permit  the  compiler  to  safely  avoid  run-time  checking 
code . 

Tt  seems  clear  that  if  o^e  starts  with.  a b i rather  awkward 
language  like  CS-4  and  tries  to  modify  it  to  meet  the  Tinman 
requirements  (or  ary  other,  perhaps  superior,  requi  rem.ents) , the  result 
will  be  an  even  bigger,  clumsier,  l&npuaoe.  The  requirements  for 
simplicity,  code  efficiency,  etc.,  may  simrly  not  be  satisfiable  qiven 
the  CS-4  startinq  point.  fS-4  does  havr  the  advantage  that  it  doesn't 
really  exist  yet,  so  there  are  no  users  to  insist  that  certain  unwanted 
features  be  kept;  perhaps  an  effort  to  first  pare  down  fS-4  to  a 
minimum,  clean  it  up,  then  build  it  up  to  the  requirements,  might  b r 
successful.  Starting  with  a simpler,  cleaner  language  in  the  first 
nlace  seems  cheaper,  and  far  less  risky. 
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EUCLID 


! nt  rnditct  i^r 

This  report  qives  a comparison  of  the  lanouaoe  IUCLI  to  the  Tinman 
l.imiiA5f  requirements  (Department  o * r(*<*nsf  requirements  for  f'inh  Order 
Computer  i'roira"i*inn  lanr'wges,  "Jipn.^n"  - 1 March  107^,  Sectier  I j) . 
for  t r 0 rurpcs,‘^  of  tlis  cn.Tcarisnn,  rlKlir  it  considered  to  be  drfineq 
oy : 

Report  r'n  t*e  f roqT^neino  lunquane  bUCLID 
K.  ".  Lamp* on,  J.  J.  H,Tr'ir'f  / K.  1.  Lonncn, 

J.  r.  *‘i  t r e I l , and  r.  J.  rop^lr 
July,  1 V 7 6 

Tirman  contains  ?t  lan^naoi  requirements.  Pis  retort  tt»n;tr»s 
fUCLIL  to  each  requi recent  i r r. iv idtia  1 1 y . It  a requirement  is  totally 
satisfied,  tre  accnmpar,yino  text  is  a summary  ot  the  particular 
mechanism  used.  (r ccasiona l ly  r c text  is  needed  if  a requirement  is 
totally  satisfied.)  If  requirement  is  nrt  totally  ralistieo,  the  text 
consists  of  a summary  of  the  shortcomings  and  such  items  as  the  scooe  of 
the  chanqes  necessary  to  fullv  r»f et  the  requirement  and  the  inouct  of 
these  changes  on  existing  imp  I e"  t r t?  t i ons  . 

fach  Tinman  requirement  t-eoins  with  an  introductory  paraurwph. 
These  paraoraphs  are  reproduced  in  t‘is  report.  In  many  cases  they  are 
followed  ty  several  sinole-line  summaries  of  features  in  the  area  of  the 
requi r ement . Usually  these  are  features  which  ar»  specifically  called 

for  in  the  requirement . * feature  enclosed  in  parentheses,  however,  is 

one  which  the  reviewers  t fought  rossihly  desirable,  ®ven  tKouqh  not 
callec  *or  in  the  requirement. 

Symbols  placed  beside  the  irt r o"uc t >r y pnraqraoh  and  the  individual 
features  indicate  the  decree  tn  ,hich  the  reoui  r mm  crit  or  feature  is 
satisfied  by  the  lanouect.  Th«  sym.trls  and  their  mearincs  err: 

T - Totally  satisfied 

b - Partially  sftisfier 

t - fails  (not  srtisfied  ft  all) 

U - Unclear  from  the  crcumertation 

*»♦  - Almost  totally  satisfied 

P-  - Only  sliobtlv  satis 4ied 

f'/A  - Nft  applicable  (used  c^rly  for  irdividual 
features  when  the  requi  r*-ment  is  not  satisfied 
at  all) 

(The  symbols  f,  r+,  and  P-  will  effen  he  ur.ee  with  requirements  which 
are  stated  in  one  nf  the  form.*  "There  .ill  be  re..."  nr  "All...”,  even 
thounh  only  T or  F are  technically  applicable  in  these  coses.) 


EUCLID 


i i 


The  rernrt  conclude?  with  two  summaries.  The  first  is  of  the 
features  of  Eirilh  which  ar*1  extraneous  to  Tinrran  and  the  des  i r ah  i l i t v 
if  retaining  each  rt  them.  Trie  second  is  of  the  lanouape  as  a whole  an  i 
the  desirability  of  modi  * y i re  it  to  brino  in  into  line  with  the  Tinrin 
requirements,. 


c I'  CL  I r 
y e j i r e ~ t 


*1 


1 


A 1 . TK‘  lenruant  will  t e fvi  rH,  The  tyre  (cr  more)  nf  oil 
variables,  components  rt  coirjosite  data  structures, 
exi  cessions,  c-'er'tions,  arc  parameters  will  be  ceterT.imMe 
at  ro^pil"  time  and  ura I tenable  at  run  time.  |he  lannusie 
will  rmoire  t^at  the  tvf  p cf  cart  variable  and  comrorent  of 
corp'site  data  structure*  * e explicitly  srecifiea  in  the 
sour  rr  ; romans  . 


T 


'Ms  r e j ; j i r * 
Le fore  use  (p. 
specification  of 


Tent  is  tiillv  •»pt  . 
f)  and  cart  oi 
their  tvrrj  . 


•'ll  identi4iers 
the  declaration 


must  4*e  declared 
t j r o ■*  t a is  t h e 


*?.  Toe  languane  will  nrrvide  data  tyoes  for  intener,  real 
(floating  poirt  and  fixer,  print),  boolean  end  character  anc 


will  provide  arrctys  (i.e.,  coniopitp  data  structuros  with 
indocile  cc-ooncnts  n4  hcroneneous  type)  ana  records  Ci.e., 
cor.f  csite  data  *tructures  vitl  labeled  components  of 
hett  rc-  enerus  ty rt)  ?s  tyre  nppfrstrirs.  ....*’ 

IntH'f  r . . . T 

Hr  a tin.  Point  . . . F 

f i v(  n Point  . .F 

6OP'  I ea  ri  .......T 

Characrer  Strino  T 

Arrays  ..............7 

Records  T 

flsCLll)  tias  m floating  mint  or  fixed  noint  data  types.  They  are 
unnecessary  for  the  nurrese  o4  the  lanouage.  Th*  other  types  are  all 
available  (pp.  1 7-22). 


the  addition  of  these  two  mission  tyncs  is  a relatively  si  male 
task.  Fixed  point  gives  th®  i>e?f  difficulty,  in  particular  in  definin'* 
acceptable  scalinr  rules  and  in  adde-4  complexity  in  the  code  jenerator. 
Out  n»ither  o4  these  is  r.  art  i cu  lar  l v dif4icult. 


*3.  The  sour  re  la 
specification  of 
ond  .’ll  permit 
variable?.  This 
Taxinj**  precisicn 
lirir jf  nreci'ion 


neu-iot  will  r°onire  dotal  (to  a scene) 
the  rrtcisicr  for  floating  mint  arithmetic 
crecision  sr  ec  i f i c a t ice  for  irdivi4uc»l 
spec i f i cat i r n .ill  te  interpreted  a?  the 
renuired  hv  the  monran  lonir  and  the 
to  re  sjr  r'nrt°d  f y the  object  cone. 


f 


r-'CLi  r 

Requirement  A3 


? 


Global  arithmetic  precision  specification  mandatory  M / A 

Indiviouhl  variable  precision  specification  permitted  ......... ..-1/ A 


ft (LID  Ves  not  have  a floating  nrir.t  tyre  at  all. 

a Idin  i such  a t y;u  to  the  lanouaoe,  with  the  capabilities  specified 
in  this  recjui  rere^t , would  be  a relatively  sir-pie  test. 


A 4 . Fixed  point  numbers  will  be  treated  as  exact  noantities 
which  have  ->  rcn~e  and  a fractional  step  si7e  which  ere 
determined  dv  the  user  at  cornpil®  tine.  Scale  lector 


Tantine^ent  will  be  done  by  the  compiler.  ....F 

Treated  as  exact  cu  entities  .....m  /a 

nanie  and  step  sire  rieterminec  at  compile  tire  ..‘'/a 

Scalin>.  bandied  automatically  ...................... .............N/A 


Fl'CLID  does  rot  h?ive  a fixer  point  type  nt  all. 

Adding  such  p typ-e  to  tbe  lenuua.ie,  with  the  capabilities  specified 
in  ttis  recui  revert , would  be  at  worst  of  ••oderate  difficulty.  There 
would  he  a moderate  impact  cri  the  cede  jeoerator  anc  the  definition  of 
acceptable  sealine  rules  is  l other*  or#* . < 1 r rjereral,  it  is  not 
nractical  to  tre?t  fixed  point  nuantities  fs  exact.) 


A*5.  Ctaracter  sets  will  Te  troeted  as  any  other  enumeration 


type.  . . . . F 

hew  sets  can  be  defined  *r  enumeration  tvpes  f 

ASCII  and  EBCDIC  a r*  provided  ................................... F 

(Conversion  capability  between  sets  is  available)  ...N/A 


E.UCL1D  does  not  address  the  question  of  multiple  character  sets, 
nor  ir  there  »ny  need  tn  because  the  lanyuaqe  does  not  surport  any 
input /nutrut;  the  native  character  set  of  tbe  raebire  is  sufficient. 

ft  would  be  relatively  easv  to  add  rhe  renuired  capability. 


FliTL  I r 

Kequi  revert  A 


A'  . Tie  Unou?5P  will  require  user  sr eci f i ca t ion  of  *-he 
njrrr.**r  rf  di -nensiors,  the  rarne  of  subscript  values  tor  eacr 
d i n r ns  i on  , and  ty:  e of  each  array  component.  The  rusher  >f 
dimensions,  the  ty^.e  ar*  hbp  (ever  subscript  round  will  be 
determinable  at  cnr-rile  ripe.  The  jpr.er  subscript  (:  ;,uoi  fill 


Dr  determinable  at  entry  to  the  array  allocation  scone.  ....it 

\u"l  e r of  niirersions  is  fixed  at  compile  time  ................... “*♦ 

Ty'*-  i*  fixed  at  comril®  tire  T 

Lower  sjoscriot  bound  is  fixed  ut  compile  tire  ..................  f 

Uf.;tT  subscriot  bound  is  fixed  at  scope  entry  f 

Suhrcripts  only  interops  nr  f r or  »n  e^ufer-tioe  tyre  ............  T 

5-uhscripts  will  be  frnr  a continuous  ranee  T 

The  HifLlh  definition  nf  array  tvoe  satisfies  m ost  r<  the  features 


o*  this  requirement  in  spirit.  PJfLIP  H tows  only  one-dimensi  ana  l 
arrays,  sc  the  number  of  dimensions  is  vacuously  fixed  at  comr  il®  tine. 
Sjoscricts  are  from  ar,  index  type,  which  ir  a continuous  ranqe  of  either 
the  integers  or  ar-  enumeration  tyre.  The  lower  subscript  bound  it  fixtc 
at  scope  entry,  p^t  f'^p i l e tire. 

in  addition,  the  type  rf  an  array  vhich  is  allocated  at  run-tim® 
can  he  a record  ..ith  alternative  structures,  with  the  particular 
structure  specified  when  the  array  i«  allocated,  by  the  lufLlt)  use  of 
the  w-rd  type,  the  type  rf  such  an  array  is  known  at  compile  tire,  put 
this  "iirht  rot  ip  in  the  scirit  of  this  requirement. 

To  arid  mu  It i -d i mens iona l arrays  to  the  l tnouaoe  is  trivial,  as  it 
is  to  require  that  the  lower  bcurd  hr  fixed  >t  compile  time.  pnr  would 
it  be  much  narder  to  riqrrously  reouire  that  the  type  of  an  array  be 
known  at  compile  time,  if  that  is  truly  -anted,  but  this  would  sncil  th“ 
elejar.t  regularity  of  nifllD's  existinq  data  structuring  mechanisms. 


A 7.  Toe  lanouace  will  permit  recced!-  to  have  alternative 
structures,  each  of  which  is  fixed  at  compile  time.  The  name 
and  tvoe  of  each  recorc  component  will  he  specified  oy  the 


user  at  compile  time.  ....1 

Alternative  structures  for  records  arc  possible  .T 

r i sr  rimiratiro  condition  may  be  ar.y  “rolean  expression  ...... ....u 


This  requirement  appfsrs  to  be  fully  'atisfied  ty  El'ClID.  however, 
although  the  cose  statement  has  a srecial  syntax  for  discr  iminat  ino 
alternative  strictures,  the  latuiane  rerrrt  makes  no  state"er,t  about, 
nor  ir  any  example  river  of,  d i sc ri  m i na t i nc  hy  nrsns  of  an  nrtitrury 
cool  ear  exrrer  sinn. 
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VI.  Assignment  ano  reference  operation  will  he  automatic*  l l y 
ieti'ec  ter  oil  oaf;*  tyr  which  no  not  manage  their  d-*ta 
storage.  The  as  si indent  r'er~tior  will  permit  any  value  of  a 
civm  ty^e  t'*  he  assignee  to  a variable,  array,  or  record 
cot  'nrnt  of  t^at  type  or  of  a union  tyr.»  containing  that 


tyre.  Reference  *ill  retrieve  the  la«-t  assvT.rd  value.  ....nt 

AutoTa’H-ca I l v defined  for  any  tyre  (except...)  pf 

Available  t^r  individual  components  .............................  I 

(Assignment  -n;.  reference  via  functions)  ........................  f 


Ir  general,  a value  of  any  tv  ie  car  he  assigred  to  a variable  of 
that  same  tyre,  subject  to  the  Fl'CLID  definition  of  identity  of  tyges. 
In  addition,  variables  which  have  altem  tive  record  itructi'r*?  can  b« 
ir.sign^d  n value  -hich  is  cn«  of  the  alternatives.  He  of  posit** 
assignment  is  not  valid;  the  fielJs  o4  fhe  record  must  he  assigned 
individually  ir  this  case.  <o.  4*)  However,  if  the  v»lue  is  of  a 
module  type  — * tener 3 l i zat i on  of  the  record  type  which  nay  or  nay  not 
include  storage  "amazement  — th*  definition  cf  the  type  must  explicitly 
snecify  t**at  assi  nnent  is  an  allowable  enemtior  (f  . ??). 


b2.  The  source  language  will  hove  a built-in  operation  which 
can  be  used  tn  compare  arv  t*»n  date  objects  (rr^rrilrss  of 
tyre)  for  identity.  ....>’♦ 


The  egualitv  operator  is  nvailahl®  for  any  two  data  objects  of  t^e 
same  type,  but  — as  for  assionment  --  if  that  type  is  a module  tyre, 
the  definition  of  the  type  must  explicitly  srecify  that  cnnparisir  is  *' 
allowalle  operation  (see  the  comments  on  rraui re"f nt  p1).  Comparison  o* 
objects  of  different  types  foiving  a false  result)  is  not  permitted 
Cp.  41). 

t a e change  nteded  to  fllny  comj arisen  of  data  of  differert  tyoes 
would  t e minor  . 


P5.  ®elatiori£l  cr  crs’tions  will  h*  automatically  refined  for 
numrric  data  and  all  types  defired  by  enumeration.  ....p 

Puilt-in  for  all  numeric  and  enumeration  types  ......T 

Ordering  can  be  inhibited  when  desired  F 


U J 
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The  si*  relational  operation  are  available  for  both  numeric 
(integer)  an.-l  enumerated  type*  (p.  41).  It  ’ s r.et  possible  to  inhibit 
the  oroe r inj  cf  enurersr®^  * vpe  s , p'w'ver. 

To  allow  inhibition  th»  nrderir.u  on  enumerated  types  woul  * h*  a 
trivial  chance. 


P 4 . The  built-in  arithmetic  operations  will  include: 
addition,  subtraction,  multiplication,  division  (with  a real 
result',  eyporentietion,  irtener  division  (with  inteoer  or 
fixea  ’'Oirt  ar-uments  ard  remainder),  and  neoation. 


Addition  T 

Subtraction  T 

Multiplication  ....I 

Division  with  real  result  f 

Exponentiation  F 

Integer  and  fixed  point  division  with  remainder  ................. T 

Negation .............................T 


Exponentiation  and  division  with  e real  r*sult  are  rot  -'efi r?i  in 
EUCLID,  +he  latter  because  the  lanouaqe  dees  not  support  floating  ooint 
at  all.  because  fixed  point  is  not  sunrorted  at  all,  the  "integer" 
division  operator  (division  with  trurc?tior)  accepts  only  integer 
operands.  in  addition  the  lenquane  h «;  a remaindering  operator,  mod. 

Adding  the  missing  orerators  to  the  lanouaoe  definition  is  » sinole 
task,  although  the  proper  definition  ol  exponentiation  for  fixeo  point 
operands  is  open  to  some  discussion.  There  is  a nooerate  to  heavy 
impact  on  the  cede  venerator,  particularly  if  two  new  numeric  tynes 
(fixeo  mint  and  floatinr  point)  are  added  at  the  same  time. 


PS.  Arithmetic  and  assignment  operations  on  oata  which  jre 
within  the  r r.nne  snecificatiors  of  the  rrcar?*  will  never 
truncate  the  most  sioniMcant  dinits  of  a numeric  quantity. 
Truncation  and  rounding  will  always  be  on  the  least 

significant  dibits  and  will  mver  be  implirit  for  integer* 
and  fi xed  r^int  numbers.  Implicit  rounding  beyond  the 

specified  precision  will  Ir  allowed  frr  floatin',  point 
numbers.  . ...» 


Never  from  the  le*t  for  data  wi*tin  rir.ee  .... 
Never  or  tb®  rinht  for  irtener  anci  fi*ed  noirt 


»♦ 

rt 
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It'  licit  ftoa^inc  point  roundin'-  hrvpmd  precision  allowe'1  V/'- 

4ur  time  checks  can  te  avoided^  ................................  f 


Tht  Irngwane  definition  requires  tnet  the  compiler  verify  it 
corpilr  tine  that  overflow  will  rot  occur  or  that  it  generate  a legality 
assertion  to  he  processed  tv  th»  oroqram  verifier  (o.  40).  Int«'-er  iita 
is  assured  throughout  the  report  tn  he  exact,  although  no  explicit 
statement  to  this  effect  is  ned*,  therefore  precluding  truncation  on  tha 
rirht.  Mhe  result  of  integer  coer 1 ions  is  required  to  be  interior  -- 
o.  4P.)  The  language  h a «;  no  fixeo  rcir.t  tvre,  so  the  question  cf 
truncation  on  the  rinht  does  not  "-rise.  *cr  ^pps  tf>*>  question  of 
roundi-r  <>t  floatinn  ( oint  data  arise,  because  that  type  is  not 
sut  ported  « i tt>er  . 

If  the  mission  data  tyre*  are  added  to  the  language,  it  will  he  a 
simple  problem  to  require  then  tn  satisfy  this  rerui  recent.  It  would  tie 
a minor  change  to  require  that  cede  he  generated  insteao  of  a legality 
assertion  io  order  tc  check  *r r evert  low  at  run  time.  It  such  a feature 
is  adci'M*  to  the  lennuane,  it  should  he  possible  to  disable  the  rur  tine 
checks . 


°*.  The  built-in  boolean  orpretion*  will  include  "in'1", 
"or",  "rot",  and  "xor".  ?hp  operations  "anc"  and  "cr"  on 


scalars  *ill  he  evaluated  in  short  circuit  mode.  . . . . h 

sh^rt-r  ircuit  and  

Short-circuit  or  r* 

lot  .......T 

Xor  r 


The  ftICLID  reporr  does  not  require  that  short-circuit  mod?  ,>f 
execution  ie  used  for  and  and  or,  but  it  contains  th»  tel  lowin’ 
st  at  erf  r.t  <r  . 41 ) : 

The  right  orerand  rf  and  neec  not  he  legal  it  the  le+t 
oner*nd  is  false;  the  rignt  operand  of  or  need  not  he 
leial  if  the  left  c;n«rard  is  Tru«'. 

The  xor  operator  is  restricted  fp  rowers? tr. 

Th*»re  would  te  almost  no  iirract  to  explicitly  require  short-circuit 
evaluation  nf  and  *np  or,  tecaus*  it  is  the  easiest  way  to  implexu. *>t  the 
3bove  necu i r erent  . extendin'?  xor  to  roole^n  nata  is  simple. 


fucl  i h 
Reaui  r»T.fnt 


t. 


F / . The  source  lancnatje  vill  ; err it 
assi-nment  o'  confer* db  l e array* 
transfers  pet  ween  record;  cr  arrays 

*t  r jeture . 


scalar  operations  and 
and  kill  r-Tfit  data 
n4  identical  louical 


f 


Scalar  operations  rn  arrays  F 

Assignment  cetween  records  and  arrays  of  conformable  type  F 


Ccalar  operations  on  arrays  are  not  cefirer!  in  E U f L 1 0 ard  the 
assignment  operation  is  rrre  restricted  than  that  envisione-1  here  (see 
the  comments  on  rerui  mment  PI).  Sr  eci  1 i ca  l ly  , assiinrent  between 
arrays  ana  receras  are  permitted  it  the  assionment  operamns  are  of  the 
same  tvre,  which  "fan1;  that  their  type  definitions  rust  be  identical 
after  certain  substitutions  =re  -ade.  Tnis  rrecludcs  assionment  oetween 
arr-avs  and  records  which  have  the  fame  locical  structure  different 
physical  structure. 

The  required  capability  is  presumably  similar  to  the  -OVE 
r PFR F n PON h I h'n  of  Cde-CI  . It  is  is  ;*  moderately  expensive  feature, 
although  its  difficulties  are  veil-understood. 


fit.  There  will  he  no  implicit  tvre  conversions  but  no 
conversion  operation  will  be  required  when  the  tyre  of  an 
actual  parameter  is  a constituent  cf  » union  tyre  which  is 
the  formal  parameter.  The  lanouaoe  will  provide  explicit 
conversion  operations  amono  interer,  fixed  point  and  floating 
point  data,  h“«-weeo  the  obiect  representation  of  numbers  ano 
their  represent ations  as  chari.ctcrs,  md  between  fixed  noint 


scale  factors.  ....b 

No  implicit  conversions  T 

Explicit  oetween  inteoer,  fix^d  point,  and  floatino  noint  .......n/a 

Fxnlicit  between  fixed  mint  sc  ole  factors  N / A 

(Explicit  between  inteoer  an n boolean'  f 

(Fxp  licit  between  inteoer  and  rrurprated  tvpes)  .................  I 

(Fxnlicit  between  different  enumerated  ty(  eO  .F 


FUCLID  lacks  the  missin-  conversion  operations  because  it  has  no 
reed  lor  them.  Fixer  mint  a no  floatin'*  mint  types  are  not  supported. 
Conversion  between  the  character  strin  1 form  of  a numter  ard  it* 
internal  form  is  rot  needed  because  the  language  has  nc  input /output. 

the  missino  data  tvm-,  are  added  to  the  lanouane,  the  runeric 
conversion  operations  can  be  Priced  at  the  same  time  at  modest  cost.  M 
inpjt  /output  is  defined,  the  fiume r i c-chara c te r conversion  is  plnnrt  *ree 
because  it  is  embedded  in  the  ir j ut /outrut  package. 


t I* CL  I (■ 

Requi  r*5 rent  e*J 


. Fxnlieit  rorvprsirr  crcr  at  ions  wilt  not  be  required 
bft-t'e"  numerical  rarrf? . Ttsr®  -*  i l I be  a run  tire  exceotion 
condition  whe~  -nv  irtc  iff  or  fixed  point  value  it 
t r i.'oc  ^ t ed . 

Implicit  conversion  (-pt.-.cf  r ri  nor  s 

Fxcertion  corriition  nr  int errr  f.n.i  1 i »e<i  point  truncation  ... 


T 

r 


T*  ( IUCL1D  report  merely  specifies  that  a rrooram  is  illeoal  it  i 
valuf  is  outside  of  the  rant  (>  of  a variable  to  which  it  is  3 s sinned;  it 
does  rot  reauire  that  «nv  cme  te  oencrated  to  elect  *cr  rucu  ',otential 
truncations  (t  . It  also  requires  fat  nr.  rvrrtUv.  recur  ourin)  the 

evaluation  of  numeric  express  ier  s (see  fe  rorurnt'  rn  rnjuir ? nent  d,). 

It  is  o simple  nrstter  to  .'da  this  rmiirrrer.t  to  tv  lao.jijqe 
definition  and  is  ccrsc'p?rt  > i t r.  the  verifiability  and  legality 
assertion  philosophy  ct  the  Umruane.  The  possibility  ot  tr  meat  ion 
should  hr  handled  in  a manner  similar  tc  tK*»  possibility  of  overflow 
(see  the  comments  on  reouirement  r;r>i. 


Hi;.  The  case  lannuaop  will  provide  operations  allowing 
pro-rams  tc  interact  -iith  *iles,  channels,  cr  devices, 
inrludini  terminals.  Thece  rreration$  will  permit  send i no 
and  receivino  teth  cats  and  control  information,  will  eoaF  le 
rro  raTs  to  cyoar i cn  l ly  assior  and  re-ssinn  I/O  devices,  will 
provide  user  control  for  exception  conditions,  and  will  not 
be  installation  dependent. 

Senciinn  and  receiving  of  dst?  r 

Senoino  and  receivino  of  control  information  F 

dynamic  aevice  assion-ent  c 

Us°r  exception  corditicri  control  ..F 

Installation  i nrier.end.eec  e ..F 

(data  formuttinn  capacilitv)  r 

(Re.  pin  : ard  writinq  of  bit  strings)  ....F 


tUCLID  has  nr  i nr ut /oufut  capability  at  all. 


Tr  auc  an  incut/cufut  capability  to  hlucilb 
t y > e envisioned  bv  this  recni re«ent , is  a 
si"T'lifyim  psnect  of  tx.  task  in  this  case  is 
start  f rum  scratch,  rather  tf  m tavino  tn 

capabilities  into  existin-  features. 


, particularly  of 
maior  task.  the 
that  the  designer 
trv  to  erbed  r.<» 


the 
on  l y 
can 
w I / J 
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Ctl  1 . The  lanquane  will  provide  '■'peratiors 

defined  a5  rr.er  sets  of  enumeration  types 
operations  will  include  union,  intersect 
con | leT'ent,  and  an  eler.ent  predicate. 

Union  

Intersection  

Difference  

Coni  leeent  

* e f ■ t e r s 

(Set  inclusion)  


peratiors  on  nato  tv;  e 
ion  types  (see  F<S).  Thts 
intersection,  difference 


Of  the  requested  operations,  onlv  the  set  complement  operator  is 
not  available  in  HlCLJD  Or.  to-/,l). 

It  would  l>e  a minor  prottem  to  and  the  set  complement  operator  to 
the  lanouaae.  The  reserved  uorH  not  could  he  used,  thus  net  increasing 
the  reserved  word  list,  hut  ether  alternatives  are  available. 
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Cl.  Side  effects  which  ?rc  dependent  on  ftp  «va  l uati  on  orc.er 
•jtnor*  • the  a*  '.aments  cf  an  ssion  will  be  evaluated 


l f * t -to-r  i ' t»t  . ...,F 

Siof  effects  r;j«t  ccc ur  in  left-to-ri'ht  rr-'er  1 

( Erf  *Hdpd  h ss  i orrrenf  5 ) . . . f 


Pfius»  of  t*-p  simplicity  of  tliCLID,  th”  only  possibility  of  side 
effects  within  **n  mrcssi^n  would  r«  in  function  reft  pence  s . T;ie 
language-  designers  have  attrni  te^  fn  rul0  nut  side  effects  entirely  tv 
severely  restricting  the  tyj  e?  of  formal  parameters  *Mch  a function  can 
have  and  allr.wino  a function  to  communicate  with  the  rest  of  =•  pro  map. 
only  tlrouih  its  onremeters  ( t.. . 1n>.  !:nf  ortim-.  te  ly,  ? f unct  i<  o can  call 
j rroceuure,  the  execution  r*  the  "rocerture  car  chan"  *hc  value  of 
a "alotal"  variable  --  a side  effect  to  th*  function  call.  fh.j«-  FjfLTD 
does  not  satisfy  this  renui rr r ert . 

Tt  w^uM  re  c fairly  easy  task  to  initially  desion  a compiler  tr 
satisfy  this  re  jui  rep-en4-,  although  we  consider  the  r eou  i r "rent  to  he 
,juf  st  iorahl  e . The  heaviest  intact  *ci,lri  te  ir  the  code  oct  ini  ?**r  , wnicr 
•ton Id  he  restricted  in  the  code  motim  it  would  *m  perritteo.  since 
there  are  few  E1J  f L I r compilers  in  existence  f-erhans  nc  re),  tt"  cost  M 
surh  n change  t o the  lannuaoe  specification  is  i n i r-l  . It  is  probihly 
better,  however,  to  change  the  r i ec i f i ca t ion  to  rule  cut  si  •»  effects 
entirely  --  i.e.,  to  forbid  rrccedure  st-tements  vitMr  functinr  rodi»s. 


C?.  Which  parts  of  an  expression  constitute  the  or-f rand'  to 
each  operation  within  that  exrrcssion  s^ouln  te  obvious  to 
the  reader,  there  will  t,«  iry  levels  of  nrerwtor  hierarchy 
an*4  they  will  he  widely  reconni7Pc!.  ....o» 

Fee  precedence  levels  r 

h n user-defiord  precedence  levels  ........................ .......T 

Operands  of  an  operctinr  are  -hvifus  n 


EulllD  has  six  t recedence  levels;  a fairly  stsnrisrn  nu’ier  chicn 
oresur  *1  l>  satisfies  t^is  rp;uirr>'on»  (•  . T,c).  There  is  no  facility  in 
t^e  l annul  te  for  chancipn  the  de  + ined  precedence  level.  Tl-«*  usual 

convention  of  I • t t-t  n-r  i it  t i ntp  r r re  t at  i on  of  operators  o*  e m a I 
precedence  holds  ft  . if),  so  tf?t  the  constructs  A div  * div  f and 
A div  a * C (A/d/C  and  a /E  *C  re r nc  ct  i ve  l v)  am  no'sihle,  =>s  i* 
A or  n xor  r for  : owersets. 

T r c'-?nue  the  l a n ^ Uttce  t require  explicit  oarertheses  in  tfe  c.tses 
T»ntinnf 1 above,  and  ntnrr  similar  cases,  c^tt'  little,  r articulc  rlv  if 
the  cm.iler't  exrrr5sion  aralv/tr  i*  syntax  ' riven.  T»>e  c ' a r>m »,  woulf 


EUCLID 

Requirement  C? 


only  te  in  the  description  n-f  the  syntax  o*  expressions  (which  woulu 
become  quite  a oi  t irore  cormlicated  thrnuoh  the  invention  ol  s nur.Lpr  of 
new  non-terminals),  hut  would  h ive  no  effect  on  any  ether  part  of  the 
compiler. 


Ci.  Expressions  of  a oiven  type  will  he  remitted  anywhpre 
in  source  rronrans  where  noth  constant'  and  r-ferences  t" 
variab  les  of  that  type  are  al  lower*.  ....t 


Tnis  requirement  is  fully  Trt. 


C 4 . Constant  expressions  will  he  allowed  in  prour^ms 
anywhere  constants  ar°  allowed,  and  constant  expressions  will 
he  evaluated  hpiore  run  time.  ....T 


This  requirement  is  fully  »et  (p.  5?). 


C5.  There  will  be  a consistent  set  of  rules  applicable  to 
all  parameters,  whether  they  be  for  rroeedures,  for  types, 

*o  r exception  hsndlino,  frr  parallel  processes,  for 
declarations,  or  for  built-in  operators.  Thrre  will  be  no 
siec^cl  operations  (e.o.,  array  suhstructur ing)  applicable 
only  to  parameters.  Uniformity  nrd  consistency  contribute  to 
ease  of  learning.  . . . . P 

Faraneter  rules  consistent  in  all  contexts  ...................... F 

No  special  operations  aj-licatle  only  tc  parameters  ............. T 


'mly  three  object  in  H'Cllh  ray  be  pa rameter i red : rroreour-s, 
• irftir-e,  ard  . The  permissible  formal  parameters  to  functions 

• f,  ri  are  mere  restricted  t^ar  those  *or  irocedures,  in  an  effort  to 

• **  side  effects.  (ire  t * <?  comments  on  requirement  Cl.)  Formal 

»re  considered  ■>  *e  variables  declared  within  ♦■hr  scope 
-»  ••  the  procedure,  tunftfnn,  nr  ty"?  1 erty.  As  siirh  they  f ave  nri 

. • x *».  t l d by  any  varieties  declared  within  srme  scope  r » a l l » r 

• - • *-«■ tier  rr onrar . 


FdfL  I C 

“Jequi  re~e nt  ( 5 


It  tiult1  be  c-  sirple  ch’inee  to  nakf  the  parameter  ru  • r *-  for 
functions  and  tyes  the  sere  as  tbrsc  r rrrfpt^uns  ?rH  wculd  -ck?  mv 
compiler  simpler.  It  is  doubtful  tKet  t^is  is  desirable;  it  w<  1. 1 i he 
p«PtPr  to  chanoe  *>.e  reouirerent  to  a^rer  with  thp  tliCLID  definition. 


C ft.  (or.r.al  ar  * actual  o?raTft*‘r<'  will  always  acres  in  tyr<*. 

Th<  •vjitCicr  • Pirirrsic-n?  tor  array  parameters  will  he 
dotr  rm  ir>al  le  at  compile  tine.  The  si/e  sot?  subscript  ranee 
for  array  Diirarteters  need  r>nt  be  det  er^inet  l «•  at  compile 
ti~r,  but  can  Pe  "ossed  as  part  r>1  the  parameter.  ....1 

Actual  and  tcrral  |.  ararrters  vill  anr*'e  in  type  .......... .......T 

Pank  o*  parameter  arrays  is  fixed  *»t  compile  time  T 

Parameter  rrray  size  and  subsrrirt  ra*"ie  can  be  passed  ..........I 


T"is  requirement  is  fully  s.tis^iec.  Actual  and  formal  r y.r  < -refers 
•sust  ire  assiqnrent-con.-at  ib  I e if  the  ♦ornal  parameter  is  treat?  f ; 
constart  and  they  rust  bp  rf  the  remc  tvre  otherwise  (pp.  4*-4A).  a- 

exce^tinr  t(.  t k> > lc.tt<  r rule  is  th^t  u formal  parameter  cr,  b» 

parameterized  -*nd  the  correspondin'’  actual  parameter  "ust  then  b j a 

specific  instance  r f the  focal  (f  r . SI-5?).  T|  i«  inclement*",  amon: 
other  tvini5,  deferring  the  fixing  nf  the  specified  array  -ror^rfies 

until  routine  invccation.  The  rrorerties  car.  he  pasted  either 
explicitly  or  irrlicitly. 


ff.  There  will  be  or ly  four  classes  rf  formal  parameters, 
for  data  there  vill  he  those  which  act  as  corrttrts 
represrnhino  the  actual  parameter  value  at  the  time  rf  call, 
and  those  which  rename  the  actusl  parameter  vfich  ■*>ust  he  a 
variable.  In  addition,  there  .-ill  . e r for-el  parameter 
class  tor  specifying  the  control  rcticn  then  exception 


conditions  occur  and  a class  for  procedure  parameters.  ,...r>- 

Act  as  constants  (call  ty  value  plus)  T 

Act  as  variables  (call  ty  reference)  ..........T 

Fxce~tion  control  I 

procedure  parameters  f 

(Act  as  variables,  rut  call  tv  vain®)  ....... ....................F 

(Act  as  variables,  result  para meter)  

i jfLIO  permits  only  tve  classes  of  rarameters:  Those  wMch  wet  as 

constants  within  the  routine  jjpd  the  classical  r a l l-hy-va  lue . there  is 
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no  class  for  exception  control  localise  tie  subject  is, 
all  by  the  Is^ruaff . Frccetiure  parc-meters  have 
considered  because  they  are  unnecessary  vithin  the  r)  e • 
of  the  larnuane. 


not  addressed  at 
nr oh ah Iv  not  been 
i m.  cons  i tie  r a t ions 


Tc  add  the  mission  parameter  classes  to  the  lanruaoe  woul'"'  ne  a 
fairly  major  chnnoe,  hut  not  ton  difficult,  the  exception  control 
oarameter  would  first  require  that  t^e  entire  ruestion  of  exception 
handliru;  *~e  addressed.  Then,  ever  i*  they  are  i r p (.omente d by  such  a 
single  device  as  a label  rara^eter  class,  additional  changes  *nul.i  lx* 
reouired  because  run  ID  has  no  labels  at  present.  Tf-*  i rtn  i e it ?ot « t ion  of 
procedure  parameters  presents  no  particular*  difficulty. 


C? . Specification  c t the  type,  rarxr,  precision,  dimension, 
scale,  and  forma*  of  fare^eters  .ill  he  optional  in  *he 
"rocedure  declaration.  None  of  therr  '•ill  he  alterable  at  nijn 


time.  ....F 

Above  properties  optional  F 

Abov*  properties  are  fixed  at  run  time  .h M 


fcUfLlh  has  no  generic  procedure  curability. 

Trie  addition  of  such  a capability  would  *e  a fairly  mairr  chanoe, 
but  a veil-understood  one. 


C9 . There  « i 1 1 be  provision  for  variable  numlers  of 
arguments,  but  in  such  case*'  all  *ut  a constant  number  of 
them  must  he  of  the  same  tvpe.  Whether  a routine  can  have  a 
variable  number  of  arguments  "'ijc.t  * e determinable  from  its 
Her  cr  irtiori  and  the  number  cf  armrerts  for  any  call  will  te 


ceterminab le  af  compile  time.  ....f 

Variable  number  of  arguments  possible r 

All  tut  a corstant  number  of  « ruunent s have  the  same  type  .......N/A 

furl  »r  of  arouments  in  each  call  is  fixed  at  compile  time  .......M/A 


»ll  t aramete  r i zed  entities  i"  FPfLIh  (procedures,  functiors,  and 
types'  have  a fixed  number  of  arguments. 


To  add  such  a capability  to  the  lannuane  would  te  a significant 
change.  * nt  the  least  problem  would  re  to  find  »r  acceptable  syntax  tor 
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thf>  routine  declarations.  Since  fUCLlh  '•emit*  procedures  to  h v toth 
open  ard  closed,  and  presumably  these  options  would  he  available  to 
routines  with  a variable  number  cf  parameters,  a capability  very  close 
tr  a m«CRO  expansion  would  have  to  be  added  to  compilers.  This 
capaoility  would  be  used  fcr  the  closed  case  and  couln  be  used  tor  the 
of  er.  case.  S;  ace  cons  iderations  would  probably  reouire  the  definition 
of  an  elaborate  linkage  mechanism  for  the  open  case,  however. 
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1wis  requi rement  is  fullv  rot.  FI'fLID  b;..?  a corstiot  declaration 
capability,  and  the  constant  can  ^e  cf  any  built-in  type,  includinq  t h» 
structure  types.  (f.  . 32) 


D2.  The  lanuuaie  will  provide  a syntax  and  a consistent 
int  m rrt  atior  t"r  constants  cf  built-in  data  typos.  'umeric 
constants  will  have  the  same  value  (within  the  specified 
precision)  in  loth  pr  r .irons  and  data  (input  or  output).  . . . . p 

literals  for  all  hui It-in  tyjfc  f* 

Consistent  interpretation  in  p,  roor ?ir  and  data  ( 


F L CL  ID  has  literals  for  all  the  "si'ple"  t.uilt-in  types,  includino 
opwersets,  but  not  for  the  structured  types  (arrav?  and  records).  The 
question  of  consistency  cf  irterr retaticn  between  pronram  and  data  doer 
not  arise  because  ELifLIh  has  no  i rout  /output  capability. 

Jt  an  I/O  capability  is  added  to  Fiiclid  it  will  he  a simple  turtner 
additirn  to  require  consistency  between  proorams  and  data  but,  as  the 
Tinman  infers,  this  can  cause  amazirioly  expensive  problems  in 
imp lementat ion . 


D3.  The  lannuaqe  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  part  of  their  declaration. 
Such  variables  will  be  initialized  -t  tbr  ti»e  of  tbeir 
a:r;...rent  allocation  (i.e.,  at  entry  to  allocation  scope). 


There  will  be  no  default  initial  values.  ,...T 

Initial  value  can  be  specified  as  part  of  the  declaration  T 

Initialization  occurs  at  allocation  srope  entry  .................I 

No  default  initial  values  ...T 


This 

definition 
f c rn i d any 


requi  remer  t is  fully  satisfied  <r> 
dies  not  srerify  any  default  initial 
coMpil«r  to  imple-ent  them. 


32)  . 
values. 


The 

but  i t 


l amuaoe 
oors  not 
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14 . Tfe  source  larrjuaoe  will  recuire  its  users  to  specify 
individually  the  rarer  of  ell  numrric  variables  * nd  the  step 
si  7P  t :r  *ixe-i  mint  variables.  The  r-.  rue  specifications 
.ill  to  i nter^reteh  as  the  maximal  rame  of  values  vhich  *•  i I l 
he  arsiyner*  tc  a variable  and  the  rinirrol  rarue  which  rust  he 
supported  by  the  ebirct  rode.  Panne  and  steo  size 

specification*  will  rot  te  irter[  reted  as  defining  new 
t y ! * s . 

bijrrric  variable  rsn<  e specification  mandatory  .................. f 

Fixed  peine  variable  steo  size  specification  mandatory  ......... .N/ a 

rtame  and  ster  size  sreci  f icat  ions  do  not  define  .1  new  tyoe  1 


F " r L T 0 wersiits  intecer  variables  (toe  orly  numeric  tyres  sui  norter 
by  t^e  len’iiare)  to  be  sr ecif ied  os  one  r.f  two  irtf,fjer  subtypes,  ir 
-v’lict.  case  their  ranee  teccires  imp  lemer.t»tion  dependent  ( ' - id). 

(o,mq»s  of  inteoer*1  ere  also  oossille.)  * 1 1 integer  variaoles  are 
consiJmec  to  be  of  the  sarc  type,  reqardless  of  their  r •one 
s,"  ec  i t i cat  ions  . 

It  is  a trivial  ctanqe  to  require  that  ranr.es  be  specified  in  all 
cases.  If  fixeu  roint  tyre  is  a due  d to  the  Isnauaqe,  sortin')  the 

f“atures  of  tnis  reouirement  to  the  properties  of  the  type  definitions 
is  ecu ally  trivial. 


05.  The  ranee  of  values  which  can  be  associated  with  .i 
variatle,  array,  nr  record  component,  will  be  any  built-i" 
tym,  any  defi‘>eH  tyre,  r r a continuous  subsequence  of  .my 
‘•numeration  tyre. 


Ranees  of  m pnurreration  tvpr  are  allowed  I 

• o arbitrary  restrictions  on  th*»  structure  of  data  ..............  T 


Ttis  rcoui  rert  ent  is  fully  satisfied.  In  rarticular,  any  s^rjetwrr 
may  contain  any  tyoe  of  structure  as  a c‘mpon»nt  (np. 


Df.  The  lenotjace  will  provide  a printer  mechanism  which  cm 
he  used  t*-  build  deta  witK  si. irea  ana/or  recursive 
sur.  s tructure . The  printer  prrporty  will  crly  affect  the  use 
of  variables  (includira  array  ind  record  romnonrnts)  of  snrre 
dat-i  tvpes.  Feint  er  variable!  will  be  is  safe  in  their  use 
is  -re  any  other  variables.  . . . . P 


g 


b 
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Recursive  and  network  structures  provided T 

►-.ancles  va  r iao  le-v«a  lue  and  struc ture-cumponent  connections  T 

Pointer  nrnp^rty  is  an  attribute  rt  a typed  variable  .F 

Pointer  property  not  4 or  constants,  affects  only  ussioivnent  t 

Pointer  urcperhy  mandatory  for  dynamic  allocation  ...............  T 

Allocation  sco-e  never  wider  thar  access  scope  ..................  F 

(fitter  tbe  value  or  the  pointer  is  rort  i f iab  le  ) ....I 

( Pr i rt e r mechanism  handles  f mredures  and  parameters)  ...........r 

(Re’iflC  and  replace  assignment  have  different  syntaxes)  ...I 

(nuilt-in  dynar.ic  variable  ere  a tier)  .a 

(Variable  ejuivalence  classes  are  declarable)  ................... f 


r u f L I !)  has  a printer  T.ec‘'nni<!^  with  the  tollowinn  salient-  features: 

* Pointers  n^int  only  to  dyramicellv  created  variables,  and 
they  provide  the  only  mechanism  for  referencing  dynamically 
created  variables. 

* Part  ot  the  declaration  of  o pointer  is  specification  of  the 
collection  to  which  it  "ay  point.  « collection  is  a orouo 
(njuDer  undetermined)  rt  variables  of  the  same  ty’oe.  The 
tvr>e  may  be  parameterized,  but  the  parameters  are  either 
fixed  at  allocation  time  r*-  the  printer  points  to  a variable 
of  a discriminated  uninn  type.  Thus  pointers  are  as 
type-safe  «r  any  otter  variatle. 

* The  notation  p*  is  used  to  dereference  the  pointer  p. 

* The  value  of  a printer  to  a collection  can  be  assigned  to 
another  pointer  to  that  same  collection.  Thus  it  is 
rossible  for  a pointer  to  point  to  a variable  which  has  been 
oe  st  rnyed . 

Jt  is  impossible  to  f^timate  how  much  of  a change  is  r>guired  *o 
modify  the  F.uri.ie  no  inter  rechanism  to  fulfill  this  renuirement,  because 
the  intent  nf  the  re^ni  rerrert  is  *00  unclear. 
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!1.  The  user  of  the  lap  iuagn  will  be  a ole  to  define  rew  i a t & 
types  n j operations  within  t.  ro?  r ?rs . 


* tf  r L I rrsrpsses  the  '•enerally  accepted  data-ctruc tur in i 
capah  -j  l i t-v,  with  no  arbitrary  restrictions  <rr.  1c-?z).  in  .edition,  it 
hfS  the  module  *ve,  i nee  ha  r>i  sr  for  dp  f ini  no  a nc*  tynt;  »»;u  my 
ooer’^ions  peculiar  to  that  t vpe  (pp.  ?2-?Z) . The  defined  operations 
con  only  ho  rrocecures  and  functions,  however,  not  infix  onr  raters. 

Th«*  chances  necessary  to  permit  the  definition  of  infix  c-j  t rotors 
on  a user-defined  tyre  would  he  si  or.i  f i cart . It  would  te  necessary  to 
ch jnor  the  syntax  of  the  module  aefinition,  hut  the  required  chinoe 
-ould  ret  te  too  radical,  fsior  char.oer  in  the  lexical  analyzer  and 
syntax  analyzer  would  he  reeded,  however. 


tit.  The  "use”  of  defined  tyres  will  be  i ndi  st  inoiii  shah  le 
fron>  built-in  types. 


There  are  no  syntactic  differences  between  built-in  types  and 
user-defined  tv"»s.  Tri  particular,  functions  rr.ey  return  vtlue-  of  anv 
ty:  e (’• . >4 ) . 


F3.  Fach  procram  ccmrnoen*  will  h.«  defined  in  the  rase 
lanjuaue,  in  a lihrarv,  or  in  the  rroiran.  There  will  be  no 
default  dec  l a r«  t ions  . 

oesically  this  requirement  is  satisfied  ty  EUClTh:  All  identifiers 

must  he  declared.  However,  scatter'd  throuohout  the  report  are  a number 
ot  entities  referred  to  as  "standard"  (e.<».,  strir  ? ty  'p  and  she 
functiors  obs  ard  odd).  Apparently  t^ese  are  interbed  to  be  standard  ^ 

extension*  to  .*»  base  definition,  but  in  «-uch  a case  it  is  difficult  to 
distinguish  there  from  tart  of  the  base  lennuaoe. 

!t  vould  be  a trivial  chance  to  satisfy  this  requirement  t y the 
fiat  ot  declarin'  the  "stara*rd"  entities  to  k>e  :arf  of  the  Uniijotje, 


- 

F 4 . The  user  kill  be  atlc,  within  the  source  lancuace,  to 
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eyt » r r*  existing  operators  to  re#  data  types.  . ...F 

Tte  only  or  r ra  t i permitted  on  ut  °r-dr  f inert  da*e  types  ar**  in  the 
*or«  v4  procedures  and  turction  calls  fro.  ??-?Z)  . 

See  the  comments  on  requirement  FI. 


f Z . Tv  pe  oetiniticns  in  the  source  lammae  will  permit 
definition  of  both  the  class  ct  date  objects  crrrrisinn  the 
tyre  and  ftp  « et  of  operation*  applicable  to  that  class.  4 
defined  type  will  not  automatically  inherit  the-  operations  of 
the  cnta  with  which  it  is  represented. 


Construction  P- 

Se  I tction  T 

Predicates  .......r 

Tyre  conversions  T 

Operations  and  data  can  he  defined  together  .....................  T 


There  is  no  specific  syr.tay  to  denoted  to  const  rite  t ion  of  ■-  value 
of  a us  * r-tef  i nod  type,  hut  the  module  definition  could  include  a 
function  definition  which  could  return  such  a value.  Selection  is 
ac  coirr  l i s hed  through  dot  cua  li  4 i cat  i <?•':  Tf  T is  i user-cef  i nt  d data 

type,  r is  a component  of  that  tvor  which  ha*1  heen  "exported"  ( narte 
accessible  outside  the  tvne  definition),  end  v'  is  a variable  of  type  T, 
then  V . C refers  to  the  instance  of  the  component  C in  V.  The  equality 
predicate  is  rre-defired  for  p~y  user-aefired  tyre,  but  it  must  be 
explicitly  exported  lefore  it  can  be  u«pd;  other  r re.dicstes  nust  he 
defineu  as  functions  or  p rccercres . Type  ernversinrs  can  also  Ke 
defireo  as  functions  within  the  ty^e  oefinitim.  (See  rp. 


Adnina  an  explicit  construction  syntax  to  the  lanouaqe  would  cost 
little.  Us i rn  the  tyre  identifier  followed  ky  a lis*  of  initial  values 
enclosed  in  parentheses  --  the  syntax  of  a function  call  but  with  the 
advantage  that  the  type  name  is  obvious  -•  is  one  possibility  (bcrro»ed 
from  CS-4).  Tte  arpecrance  o 4 such  construct  would  cause  the 
execution  of  a particular  routine  defined  in  the  tyre  body  (aoain, 
borrowed  from  Cc-4).  Such  an  i rrr  l e»fnt ; t i on  «nuld  have  only  a nederate 
impact  cr  the  syntax  analy7fr  of  a corniler  and  almost  none  elsewhere. 


Full!  I n 


F ervji  rr -ent  F ‘ 

products  of 

ex i s t ir  r tvrrs 

( i . e . , as  rrray 

anl  record 

clo'tes),  by 

discriminated 

nr i rr  ( i .e  . , ns 

tie  union  cf 

disjoint  tyr^r)  ard.  ns  tt**  rn  *>r  set  of  sr  enumeration  tvre. 

These  o<*  t ini  t ior.*  will  f c nrrcpss(“r  ertirely  at  compile 
ti*“.  . . . . T 

Enumer'tion  .T 

Cartesian  pro /-jets  (rocrr'T?)  ........T 

Discriminated  un  i or  T 

t’tivorsrt  of  an  eru nrr at ior  type  .................................  » 


T *'  1 5 requirement  is  4t:llv  satisfied  (pr  . 1 7-?2,  24 -?!>>. 


E7.  Type  Definitions  tv  tree  union  fi.e.,  union  of 
non-di s j oi nt  tvpes>  and  rut  sett  inn  are  not  desireo.  . . . . d 


ll'CLTh  arpears  to  satisfy  tHs  rerjirenert.  It  has  no  overlay 
statement  arc!  even  requires  tte  compiler  tc  deck  that  machine-dependent 
records  (ir.  „hirh  tte  us°r  sreciH»«  the  tit  location  c4  -'ll  fielos)  jo 
not  have  verlarpinn  fields  (r  . <4).  Th^re  ^re  also  numerous  references 
to  a "ncr-overlap"  property.  Unfortunately,  there  sre  also  tte  rmcents 
of  main  variables,  entire  variables,  ana  part  of  a variable  wlich  ye 
have  rot  l een  able  tr  tethom,  in  srife  of  the  report's  claim  that  they 
are  defined  preriselv  Fpp.  33-34,  36-3^).  The  lanonaoe  report,  in  the 
area  »here  these  concepts  arise,  raises  so.me  questions  of  overlaopint 
'/*hicn  are  not  re^olvp/4. 

The  scone  nf  any  reeoed  charoes  is  impossible  to  determine,  since 
it  is  impossible  to  determine  vhat  tke  needed  chanoes  are.  ^robahly 
only  a clear  exploration  in  the  rerort  is  reouired. 


fc°.  when  definin-j  a tyre,  the  user  will  re  able  to  specify 
the  initialization  a no  finalization  rrccedures  for  the  tyie 
and  t^e  actiors  to  he  taken  at  the  time  c f alteration  and 


Deallocation  c t variables  of  that  tyi  r . ....T 

initia  l i zatiori  ...,T 

Finaliratinn  . . . T 

• l location  art  ions  ...... T 

Peal  location  actions  ...........T 


r 
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FI.  The  l .inqi'ficje  will  pi  lew  ♦’he  user  to  distinguish  between 
scr  ir  of  allocation  and  score  rf  ?ccfrs.  ....1 


f.'CLID  has  the  typical  Alunl-lik*  nesting  of  scones,  w i t ►»  tn® 
declaration  of  =>n  identifier  in  or  inner  sconr  overriding  any  definition 
in  an  outer  score.  Thus  a varied*  declare-*  (existino)  in  an  ojter 
scope  could  he  inaccessible  in  sort®  i-ner  scone.  If  is  also  -ossicle  to 
declare  ar  identifier  to  be  pervasive  in  sore  scope,  which  foriifs 
another  definition  of  that  identifier  in  any  inner  scope.  |nu«  tie  js®r 
can  srecity  that  the  scores  nf  allocatin'-,  arid  access  ar"  ioer«-ic;l  (m d 
not  reressarily  the  entire  program).  <S®e  rr  . 35-36.) 


F <? . The  ability  to  limit  the  r.ccess  t--  serarately  defines 
structures  will  be  available  both  where  the  structure  i« 
defined  and  wher®  it  is  used.  Tt  will  re  possible  tc 
associate  new  local  ramps  with  senaratdy  defined  program 


comconrnts.  ....d 

Allowable  operations  can  be  limite-*  T 

Access  can  De  limited  wher®  used  ............................... .•'+ 

External  declarations  need  net  all  have  the  sane  score  N/A 

Naming  conflicts  can  be  avoided  (renaming)  ..I 


Those  properties  of  ary  user-defined  data  tyre  which  are  to 
accessible  in  the  program  trust  i®  explicitly  declared  (exported).  3'ich 
properties  are  then  fully  accessiDle  throughout  the  access  scope  nf  any 
datum  if  that  tyre.  Access  on  the  user  side  can  be  limited  through  the 
device  of  a module;  ore  of  thr  properties  of  a rrooule  is  that  it  torn*,  a 
closer  scope  — any  interface  with  entities  outside  the  module  »jst  he 
explicitly  declared  (trey  rust  re  imported).  This  device  satisfies  the 
letter  nr  the  Tirman  recui  r ement , but  it  is  probably  mere  complicated 
than  *he  authors  rf  the  Tinman  er v i s i one  - . There  are  no  declarations 
external  to  th®  program;  the  CUCLID  larotiaoe  retort  does  not  address 
libraries  or  controls.  The  bindiro  operator,  rives  a renaming 

capability,  amor.r  other  thin-s. 

The  chanq®s  necessary  tr  add  libraries  to  the  lannu-ae  ire 
discussed  under  r rpu i rrr ent s F4  <nd  F5. 


F 3 . Tt®  scoop  cf  inentifiers  will  he  wholly  determined 
comcil®  time. 


at 
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This  requirement  is  fully  net  (r  p . 35-36). 


F4.  < variety  of  ao  p li  c at  i rn-cr  ie  rted  data  and  operation? 

*ill  he  available  in  libraries  ard  easily  accessible  in  the 

lani'3',(.  ....F 


The  [IJCLID  lan'iuaqe  report  does  not  address  the  question  of 
libraries. 

Adainn  a library  accessing  capability  to  the  language  is  a minor 
task.  Provided  that  the  capability  is  not  too  elaborate,  its  iepact  is 
jsually  confined  to  the  front  end  of  the  compiler. 


F 5 . Proerarr,  components  not  defined  within  the  current 
oro'  ran:  and  not  in  the  base  lanoufoe  will  he  maintained  in 
compile  tine  accessible  libraries.  The  libraries  will  oe 
capable  n f holdino  anything  definable  in  the  lanouaqe  and 
will  net  exclude  routine?  whose  bodies  are  written  in  other 


source  lanouaees.  ....F 

Program  component  libraries  accessible  at  compile  ti"<e  ..........F 

Libraries  can  contain  foreion  lanruaqe  routines  ................. F 

Interface  recui  regents  checkable  at  coirnil0  time  F 


The  FUfLID  laneuace  report  does  not  address  the  question  o* 
libraries . 

See  the  comments  on  repuirenert  F4.  Peouiring  that  interfaces  oe 
checked  at  compile  time  would  make  impact  of  *i  litrary  facility  somewhat 
more  expensive  than  those  comments  sunoest,  hut  it  cculd  still  be  done 
for  a moderate  cost  at  rnst.  The  erp’test  drawback  to  that  requirement 
is  that  it  would  require  the  relevant  libraries  to  be  accessible  at 
comoilr  time  and  would  oenerally  reduce  the  compiler's  thrcvqhput 
substantially. 


F a.  Libraries  and  Compnols  will  be  inoist irauishab le . They 
will  v,e  capable  of  hrldina  anytk'inp  definable  in  the 
lanquane,  and  it  v.  i L L ce  nrssible  to  associate  then  .ith  ;.ny 


fUCLK 

'requirement  FO 


?> 


level  ot  r>r  c ird"-t  i no  activity  from  systems  throuyh  project? 
to  individual  •'ro-’rati*: . Th.*re  *ill  h?  many  specialized 
cor-^ols  f.r  libraries  any  user  specified  subset  of  w n i c h is 


i !t>fr?ni  ate  lv  accessible  from  a oiven  nronrarr  . . . . . f 

Libraries  and  compocls  wi  1 1 t?  irdistinouishable  F 

I .T.T.eui  ate  l v accessible  sublibraries  at  any  level  F 

T1'"  FUCLID  lanouaoA  report  ^pes  not  address  the  question  of 
libraries. 

Sec  tbe  comments  on  reruirement  FA. 


F 7.  The  source  lanauaqe  will  contain  standard  machine 
inderenaerit  irterffccs  to  machine  dependent  capabilities, 
includin'!  peripheral  equipment  and  special  hardware.  ....F 


EUCLID  b as  no  sucb  facility. 

AdiJiny  such  a facility  tc  Fl'CLID,  or  to  ’ny  laonuane  for  that 
natter,  should  rot  fce  toe  difficult  a task.  The  hard  (and  expensive) 
part  is  deciding  which  machine  dependent  capabilities  are  co^sori  enouoh 
and  useful  enouoh  to  warrant  inclusion  in  the  lanouaoe.  Once  they  hive 
been  oete rmi ned,  it  should  be  fairly  easy  to  invent  a syntax  for 
accession  these  capabilities  --  particularly  so  in  a lanquao*  as  clean 
as  FUfLID.  Tbe  costs  to  the  conriler  are  then  a direct  function  ot  the 
elaborateness  of  the  capability  --  the  number  of  new  syntactic  forms 
which  rust  he  analyzed,  tbe  number  c*  now  code  seouences  which  "ust  be 
generated,  etc. 


FUf L I r 

i^fTui  G1 


<V> 


t*1  . The  language  will  provide  structured  control  rr.e  chaoi  sms 
For  sentient  i f.  I , condition.'  I , iterative,  and  recursive 
control-  It  will  also  provide  control  structures  For 
(pseuor)  parallel  procession,  exception  handlim,  and 
asynchronous  interrupt  handling.  ....» 


Sequential  execution  T 

Concitional  execution  ..I 

Iteration  ...............T 

Recursion  . ................T 

(Fs"ud')  parallel  procession  ...F 

Exception  hand  linn  f 

Asynchronous  interrupt  handlin';  ................................. F 

rontrol  structures  from  a small  set  o4  simple  primitives  ........T 


FiKLID  hes  the  usual  intra-prooram  control  structures  of  seouential 
execution,  conditional  executirn,  iteration,  and  recursion  fpp.  45-53). 
These  structures  are  formed  from  a small  set  of  primitives,  hut  can  be 
used  to  build  nuite  elotnrat®  mechanisms,  particularly  the  loooioc 
structures  with  t^eir  multiple  exits  and  parameter  value  Generators 
(cp.  44,  4»-5P). 

F'lCLIh  has  no  parallel  irocessirc,  exceftitn  handlinq,  or 
async^onr-us  interrupt  handlim  capabilities. 

Addins  the  mission  features  to  the  lannueue  would  be  a major  tast. 
»’e  do  not  believe  that  an  onod  set  of  rarallel  processing  capabilities 
has  yet  been  designed,  for  example.  The  desion  effort,  then,  is  a major 
tash  in  itself.  Assuminn  that  whatever  the  final  Hesinn  is  it  will  be 
elaborate,  the  imract  on  com.iilers  will  be  substantial. 


. The  source  lanquaoe  will  provide  a "CO  TO"  operation 
applicable  to  program  labels  witoin  its  most  local  scope  r»t 
definition.  ...,F 


Cl  CLIO  has  neither  a goto  statement  nor  labels. 

Adeline  this  capability,  as  stated,  to  the  language  would  be  a minor 
Proh  ten , as  the  issues  are  well  understood.  tven  adding  a slioh*ly  more 
elaoorate  goto,  rermittino  transfer  fro,r  a scope  to  any  containing 
scooe,  would  cost  about  the  same. 
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h*.  The  conditional  contrd  structures  will  he  fully 
pa rt i t i oreo  and  rill  permit  selection  among  alternative 
cc m • utat inns  based  on  the  value  of  a r,oolear  expression,  on 
th<e  subtyre  of  3 value  fro*  a d i s c r i mi na ten  urior.,  or  on  3 
roe.-ute'4  choice  aronc  labeled  v It  ernati  ves  . 

Oared  cn  boolean  expression  ............ ....J 

n?sr p r.n  tyre  -from  discriminate-*  union  .......................... T 

°ase-*  cn  computed  choice  amonn  l staled  alternatives  T 

Ml  alternative  must  be  accounted  for  f 

Simple  mechanisms  will  be  suoslied  for  cof'cn  cases  T 


FhCL  ID  completely  satisfies  this  requirement,  with  the  exception 
tf  at  tie  use  of  a como l ementary  clause  (else  after  if  then  and  otherwise 
after  case)  is  optional  (do.  46-4/). 

To  require  t^e  complementary  clause  in  all  cases  is  a trivial 
change  to  the  lannuare  and  fry  compiler,  hut  ve  consider  it  a 
questionable  requirement. 


04 . Thp  iterative  control  structure  ..ill  permit  the 
termination  condition  to  aruc-nr  anywh»r»  in  the  loop,  will 
require  control  variables  to  be  local  tc  the  iterative 
control,  will  allow  entry  nnlv  at  the  head  of  the  loop,  and 
will  not  impose  excessive  overhead  in  clarity  or  rur  the 
execution  costs  f«r  common  special  case  termination 
conditions  (e.a.,  fixed  number  of  iterations  or  elements  nf 


an  array  exhausted).  . . . . P ♦ 

Termination  can  occur  ary where  in  the  loop  ...... ................T 

Multiple  terminat ino  predicates  ore  rossiblr  ................... .T 

Entry  permitted  only  at  the  loon  head  ....T 

Simple  cases  are  clear  arc  efficiert  .pt 

Control  variable  is.  local  to  the  loop  ...,T 

Control  value  is  efficiently  available  aft®r  termination 


El  clip  has  t <►  o iterative  control  structures:  4n  "infinite  loon" 
structure  and  a parameter-controlled  structure  (a  syntactically  clean 
version  of  the  *lucl  for).  fer  noth  r f these  any  number  of  exit 
state-erts  can  te  used  arywhrrr  within  the  loer  tc  exit  to  the  statement 
immediately  after  the  loop,  in  the  for  loop,  thr  termination  test  is 
always  executed  at  the  top  of  the  loom.  The  loop  parameter  in  the  for 
loop  is  local  tn  the  loop  and  is  treated  as  a constant  within  the  loop 
body . (pc.  4«-*;r) 


eoci  ir 
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simple  c?Sf  s of  loot:  terrrin.it  ion  will  he  handled  efficiently,  hut 
they  pr.y  not  he  clear  because  4bey  require  a rrcorarrmed  exit  statement 
at  the  expropriate  point  ir  the  loot;  there  are  no  special  syntaxes  for 
cop  ■no*'  t »rT  i r.at  i ro  conoitions  other  than  these  handler)  by  the  for 
statement.  The  • oor  control  variable  is  not  efficiently  available  after 
loon  termination;  it  must  he  explicitly  assigned  to  some  variable 
accessit-le  in  the  co^tainim;  scene  before  exit. 

Tf  ' cost  of  odd  inn  the  miss  in-  part*;  of  this  recuire-ent  to  the 
lanrum.  c would  be  modest.  For  example,  a si"plc  addition  to  the  loop 
state*ert  would  implement  the  common  hes  cl-ot  - loon  and  tail-of-loop 
Rcolear  * erminating  conditions  (while  and  until).  An  equally  simile 
addition  +n  the  exit  statement  could  be  used  to  assii,n  the  loop 
parameter  only  uicn  exit. 


G5.  Recursive  as  well  as  nmrecursive  routines  will  be 
available  in  the  spi.irre  lannuf.oe.  l *■  will  not  be  possible  to 


detiee  procedures  within  the  b"riy  of  a recursive 
procedure.  ....“ 

No  recursive  procedures  withir  recursive  procedures  ............. f 

(taxi tut  depth  of  recursion  c^n  b.e  specified)  ,.r 

(Recursiveness  must  be  specified)  .............. ....h 


All  rcutines  in  EUCLIh  are  potentially  recursive,  withrut  any 
explicit  declaration.  Fecause  of  this,  and  because  a routine  hodv  can 
contain  the  definition  cf  another  routine,  it  is  possible  to  define 
recursive  procedures  witnin  ?.  recursive  procedure. 

The  lannuaqe  should  be  modified  to  require  explicit  specification 
of  recursiveness . (.'nee  this  is  done,  it  would  he  possible  to  enforce 
the  ernstraint  ayairjt  rerursive  procedures  within  recursive  procedures, 
if  this  is  truly  desirable.  In  ary  case,  run-tine  efficiency  can  *•<«» 
obtained  in  qener'1  if  the  compiler  is  not  required  to  assume  that  all 
routines  are  recursive.  Tne  actual  cost  of  such  a change  on  compilers 
would  he  modest. 


f-6.  The  sourc«*  language  will  provide  a parallel  procession 
canatlity.  This  carelilitv  should  include  the  ability  tc 
create  and  terminate  (possible  pseudo'  parallel  processes  arc) 
for  t*esr  processes  to  -tain  exclusive  use  of  resources  d"rino 
specified  portions  of  their  execution.  ....I 


F"d  I h 
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>o 


a r>  I ^ to  create  and  terrrir'»te  parallel  procr'ses  ....... 

•’rcrpss  can  oair  exclusive  use  of  resources  ........... 

no  parallel  routines  within  recursive  routines  

n c routines  within  parallel  routines  

•'axinur  number  of  simultaneous  instances  are  declarable 
(Access  rules  are  enforced)  


ri'CLI*'  eoes  not  surocrt  parallel  prccessir’'  at  all. 
•<ee  the  consents  under  recuirenent  f-1  . 


j?.  The  execution  han^lino  crntrol  structure  nill  permit  the 
us^r  to  cause  transfer  tf  control  arid  data  fer  arty  error  or 


exception  situ-tir"  which  niont  occur  in  a rroaram.  ....( 

ProuraTi  car  oet  control  for  any  exception  .....f 

Parameters  can  be  '■sstpc  ■•/* 

Can  ( *»t  out  of  any  level  rf  c n»st  of  control  ...................  V /A 

fan  handle  the  exception  at  ary  level  of  control  M/A 


Fl'CLTD  does  not  sutuort  exertion  hanrilinn  at  all. 
see  th<*  comments  under  rcuuircment  r 1 . 


F 

N / A 
;x/A 
N / A 

u ! ft 


l 


GA  . There  will  be  source  lanouaue  features  which  permit 
delav  on  anv  control  nett  until  sore  srecified  time  or 
situation  has  occurred,  which  rermit  specification  of  the 
relative  priorities  amonn  parallel  control  paths,  which  dive 
access  to  real  timm  clocks,  which  permit  asynchronous 
hardware  interrupts  *0  be  treated  as  any  other  exception 
situation.  ....F 


Priority  specification  

Synchronization  via  wait/enable  operations  ...................... F 

•ait  *n r end  of  real  time  interval  ........................F 

*»aif  tor  end  of  simulated  tire  interval  ......................... f 

wait  tor  hardware  interrupt  .........F 

(Can  enable  «nj  disable  interrupts)  F 


i 

j 

1 

\ 


» 1:  r l 1 n foes 

interrupt  hondlinc 


not  surport 
a t all. 


parallel 


process  irn-  or 


a sync  h ronous 


J 
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nl.  The  source  l -inou.ioe  w 1 1 l te  free  forme*  with  an  explicit 
st:<t**r>ent  delimiter,  ►ill  allow  t*ie  use  (if  rne^rni  cn  1 1 v 
sionificant  identifiers,  will  he  base  i or  conventional  fcrr», 
•.ill  hive  a sirflp  unit  err  and  easily  r-irsed  nram.Tar,  will 


not  provide  unique  notations  for  special  cases,  will  not 
permit  abbreviation  of  identifiers  or  kr v words,  and  will  be 
synt - ct i ca  l ly  unamhiruous.  ....P* 

Fr^e  format  with  strt°ment  terminator  .........I 

n men  i c identifiers  n n <■  s i 1 le  ...................................  T 

dased  on  conventional  forms  I 

Simple  grammar  T 

\o  srecial  case  notations  Pt 

No  »bt rev i at i ons  of  identifiers  or  keywords  .....................  T 

L'nan  t i ouowS  ::r  nmmar  -.1 


ninth  uses  the  semi-colon  «s  r 'tatemert  terminator  io  oeneral  and 
the  er.u  of  a lin®  in  certain  cases,  basically,  the  end-ol-line  is  a 
st  atpe.of.t  terminator  whenever  the  combination  of  the  last  tt.ktn  on  the 
line  and  the  next  to her  (the  report  says  the  first  to ten  on  the  next 
line)  mikes  it  clear  ttat  the  l.st  token  or  tse  lire  is  inceeo  the  end 
of  thr  statement.  The  rerert  then  qi'/es  two  lists  of  last  tokens  and 
next  tokens  which  srt'cify  when  th“  imt  licit  end-of-statement  occurs.  Je 
h»ve  not  verified  that  the  concent  and  the  specification  agree.  (c.  1i) 

T l - only  kno.  p srtcial  case  notations  ar e the  conditional  escape 
state^rnff, ; exit  when  non  return  when  ((  . 44).  Those  could  he  written 
as  part  o 4 ar.  if-then  with  a neoliiible  extra  eftort. 

Tte  lannuaoe  rerort  contains  two  descriptions  o*  the  grammar:  A 
formally  ambiguous  ore  ♦o  be  read  by  humans  and,  in  an  appendix,  >r 
uoanl'i  incus  one.  wc  have  not  verified  that  the  two  describe  the  sc"1* 
l amuaue . 

To  r-move  the  conditional  escape  statement*'  from  the  lanauo-e  would 
make  compilers  sim-ler  and  cheaper  to  implement  ana  maintain,  hut  only 
slinhtly.  The  sane  could  he  said  about  reouiring  a semi-colon  at  th» 
end  r * each  statement,  but  the  hi. min  factors  considerations  pf  kin  > it 
required  only  wh*»n  needed  aroue  iaain«‘t  ♦■his  --  provided,  cf  course, 
that  the  semi-colon  is  indeed  required  only  ►her  necessary  3rd  ores  not 
introduce  any  worse  human  factors  rrohlr^s.  fnf orturat- ly,  -ven  if  the 
existing  definition  («■*  when  t^r  semi-colon  is  reouired  is  "richt",  if 
E'JCLlh  is  expanoef  to  anythina  close  to  the  Tinman  rerui  rorrent  s it  will 
probably  be  iif.rorsitle  to  k«i.  this  feature  in  any  earily  jnderrtood 
form. 


>2.  The  user  -ill  not  he  able  to  mp-fify  t‘e  source  lanoija  ,o 


A 
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syntax  . Spec  i f i ca  l I y , He  will  nrt  he  able  to  modify  operator 
hierarchies,  introduce  new  precedence  rules,  define  new  key 
word  forms  or  retire  new  irtix  orer«tnr  precedences.  ,...l 


Tlis  requirement  is  tullv  m-»t. 


H3.  Th*  syntax  o4  source  language  programs  will  be 
compcsarl * from  a character  set  suitable  for  publication 
purposes,  but  no  feature  o4  the  language  will  be  inaccessible 
usior  the  OA  character  ASfiJ  'id-set.  ....F 


The  language  character  set  is  irrp  l enentat  i on  dependent  and  the 
larnuai  r designers  suggest  several  alternatives,  one  of  which  includes 
t H p lower-case  characters.  Lower-case  letters,  when  available,  *re 
considered  identical  to  the  corresponding  ti.-per-cas®  letters.  However. 
(d.  ID 

It  would  be  a simple  matter  to  fix  on  a single  character  set  which 
is  contained  in  the  ASCII  6A  character  subset.  The  language  designers 
have  suigested  cays  4cr  doing  this  (p».  r>P~59). 


HA.  The  language  definition  will  provide  the  formation  rules 
for  identifiers  and  literals.  These  will  include  literals 
for  numbers  and  character  strings  and  a break  character  for 


use  internal  to  identifiers  and  literals.  ....p 

Hrf -k  character  exists  

(Literals  are  «,e  l f-i  dent  i f y i no  as  to  tyne)  ......................  T 

(Pit-string  literals  for  anv  tyre)  ..................... .........P 


FMCLID  has  a break  character  for  identifiers  (but  does  not  specify 
what  it  is),  but  not  tor  use  within  literals  (p.  11).  Literals  of 
differert  types  h ve  different  syntaxes,  numeric  (integer)  literals  may 
ne  expressed  in  octal  and  Hexadecimal  notation  as  well  as  decimal. 
There  is  no  prohibition  acainst  continuing  lone  character  literals 
Deyond  the  end  of  a line.  (o.  1A) 

The  flank  could  anoarently  if  used  as  a break  character  in  numeric 
literals.  The  cost  of  such  a feature  would  he  minor.  It  would  be 
equally  simnle  tr  retuire  that  Icon  character  literals  Pe  broken  at  the 
end  c4  p line.  Thi?  could  he  done  by  srecifyinc  4h»4  two  consecutive 
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R e nil i r on>ent  HA 


33 


character  literals,  with  rostihly  i nte  rver i nc  blanks,  comments,  and 
eods-o t - l i ne,  are  to  be  concatenated  into  r sinqle  literal.  (EUCLID 
already  specifies  a special  meet nism  frr  denctino  tKe  apostrophe  — the 
character  strimi  literal  bracket  --  inside  a character  strioo  different 
^roT  the  co-rmon  "two  npnstronhe^  Tean  one".) 


Hr..  TH*«re  will  be  ro  c ont  i nue  t i on  of  lexical  units  acrcss 
lines,  but  t*-ere  will  te  a eay  to  include  object  character*, 
suri:  a*  <*  n c - o t - 1 i n e in  literal  strings.  ...,T 


The  lanouacie  report  does  not  sperity  that  lexemes  cannot  be 
continued  across  the  end  of  a line  (other  t h a r the  character  strin; 
constant,  see  tte  comments  on  requirement  HA),  but  the  implication  is 
strom*  throuobout.  This  is  probably  an  oversight  in  writ^nc  the  rco^rt. 

f n.cchanism  is  specified  frr  includino  ?nv  object  character  in 
literal  strinos  (• . 1A). 


H6 . Key  words  will  he  reserved,  will  he  v**ry  few  in  nurher, 
will  be  informative,  and  will  not  be  usable  in  contexts  where 
an  identifier  can  he  used.  ....«! 


The  EUCLID  report  specifies  ftl  "wrrrt  symbols",  special  symools 
comprised  of  alphabetic  characters  (r?.  1?).  They  are  rioorously 
reserved;  they  nay  not  he  used  as  identifiers  in  any  context  (n. 
However,  throughout  the  report  are  references  to  "standard"  entities, 
which  usually  have  at  least  one  identifier  associated  with  them.  The 
intent  of  these  "standard"  entities  is  unclear  (see  the  comments  on 
reouirerrent  F5)  and,  in  particular,  it  i«  not  clear  that  the  identifiers 
are  reserved.  These  "standard"  identifiers  nre  few  encuoh  that  EUCLID 
has  relatively  few  key  words  in  any  case.  The  only  "uestion  is  whether 
they  are  reserved  or  net. 

If  any  champ*  is  r'»eded,  it  would  t <ve  a reglioihle  cost. 


H 7 . The  source  larnuaoc  will 
convention.  (oirmerts  will 
code,  will  be  introduced  bv 


have  a "indie  uniform  comment 
be  easily  d i st  i ngu  i : l ab  le  fro-" 
a *im»le  (nr  pnsriMv  tvn) 


1 


t u r l i r u 

Recui rerent  H7 

lanouaae  defired  characters,  will  permit  any  combination  of 
characters  to  aprear,  will  te  able  to  ajpear  anywhere 
reasonable  ir>  nrcr-rans,  will  ^utcrat  i c a l ly  terminate  at 


enc-of-line  it  net  o*bfrwise  t e r n i nated , and  will  rot 
prohibit  autoiw.  ti  c ref  ormr-tt  inn  of  prccrems.  ....He 

Hr  i ♦ cr  •»  conmert  convention  I 

Lock  different  frem  code  T 

bracketed  by  one  ;«r  two  c^erccfers  T 

tan  contain  any  characters  

Cd-  appear  anywhere  reasonable  T 

Trrninated  by  the  end  of  the  line  F 

fcirtible  with  automatic  r e f nrmatt  i n>>  T 


T/ie  lanquaqe  report  specifies  a single  concert  convention,  which  is 
to  include  the  comments  fetween  braces  ({  and  }).  However, 
implementations  are  permitted  tr  realize  the  braces  with  alternate 
symbols,  the  ones  specifically  suoqe'tea  beinn  /*  ard  */.  Comments  can 
contain  any  character  other  than  the  closinq  brace,  can  appear  anywhere 
reasonable  foot  embedded  in  a leveme),  and  are  not  terminated  by  the  end 
of  a line.  They  can,  of  course,  look  like  code  if  cleverly  positioned, 
but  no  more  so  than  most  comment  conventions.  (pp.  1?,  5Q) 

It  would  he  a simple  chanae  to  allow  the  end  of  a line  to  terminate 
a comment.  This  would  also  tend  «-o  rpdnCe  the  ability  to  moke  comments 
look  like  c ode . 


Hh . Toe  lanquaoe  will  rot  permit  unmatched  parentheses  of 
any  kind.  ....T 

This  requirement  is  *ully  ",et. 


H9 . There  will  be  a uniform  referent  notation.  ....P* 


ryce»t  that  functions  cannot  arpear  on  the  left  of  an  assignment 
statement/  this  reoniremont  is  fully  satisfied.  The  notation  for 
function  references  and  nrravs  is  identical.  In  particular,  arrays  can 
have  structured  corrr  onents,  functions  can  return  structured  values,  and 
the  s.*re  rotation  is  used  to  reference  a component  of  a structurec  array 
and  a comronert  of  a structured  function  result. 


?!'CL  I n 75 

uppuirtrert 

Joeing  the  atility  to  assi'”^  to  a funrtiop  reference  wfuld  be 
fairly  "xpens  i ve , and  probably  not  worth  the  cost. 


f 


>♦10.  language  defined  symbols  a.poearirn  in  the  same 

context  v;ill  >»fve  essentially  different  meanirns. 


* relatively  laree  number  of  symbols  ir  EUCLID  have  multiol" 
meaninis.  Fcr  example,  ♦ , - , and  * a re  used  as  mv«»rset  orerPt^rs  as 
well  as  numeric  ones  (representino  union,  difference,  and  intersect  ion, 
r»soeetive  lv> . This  has  som?  historical  justi f i cat  ion,  but  oives  rise 
to  the  croblems  '■xnresseci  in  rhe  text  of  this  r equi  r ement . In  addition, 
<=  and  >=  denote  set  inclusion  a$  well  as  the  obvious  numeric 
re  latirr.a  Is,  and  the  latter  is  even  used  tor  logical  implication1  (This 
last  is  a fluke  c 4 an  "incorrect"  soe ci f f ca t i on  of  the  representation  of 
tte  Rorlean  values.) 

To  remove  these  multiple  use  syncol*  is  an  easy  task.  They  should 
Ke  retained  fur  their  numeric  neaninqs  and  new  key  words  invented  for 
the  other  uses.  The  cost  of  such  a change  fs  negligible. 


c i'  c l I n 

^rr.uir^rent  II 


rf, 


II.  There  will  he  r,o  defaults  ir  programs  which  affect  the 
program  Ionic.  Ttat  is,  decisions  which  affect  program  Ionic 
will  Ip  s-ace  either  irrevocably  '.hen  thp  lanouaot*  is  ’•’efineu 
c r explicitly  in  each  'r on ram.  ....P 


EUCLID  contains  a relatively  large  number  of  implementation 
I *epender.t  defaults  for  such  a modern  Inn  mane.  One  section  of  the 
! hr  iua'’c  report  (section  13)  specifies  rimmuii.s  for  some  of  these,  bu’ 

< the  imf  lementat  ion  d erDndpnce  is  still  npesfnf.  F ev  of  these  defaults 
will  affect  program  looic  (the  rmnP5  of  the  sinned  and  unsigned  integer 
types,  which  will  he  fixed  bv  the  hardware  of  the  object  machine,  arc 
" x cep  t i on?  ) , *-ut  *he  dependence  Hn*s  r^’r  that  pronrams  which  com|  i l 
correctly  on  one  romriler  may  have  to  he  modified  to  compile  on  another. 

It  is  a simple  task  to  specify  the  default  values,  and  to  eliminate 
the  signed  and  unsigned  integer  tv>  es  (requirino  an  explicit  range 
specification).  The  problems  rf  enforcing  these  srec i f i cu t i or s bv 
assurine  that  no  compiler  exceeds  them  might  be  insurmountable,  even  in 
the  relatively  tightly  controlled  DOD  environment. 


I?.  Defaults  will  Ke  provir'ed  far  special  capabilities 
affecting  only  object  representation  and  other  properties 
,hich  »he  trcgrar.rir  does  net  knew  or  care  about.  Such 
defaults  will  always  mean  ftat  the  nrnrira -mer  does  not  care 
which  choice  is.  made.  The  programmer  will  be  able  to 
override  these  defaults  when  necessary.  ....Pt 

Defaults  specified  for  don’t  care  cases  

Programmer  car  override  the  defaults  P+ 


FUCLID  dees  provide  defaults  for  ’he  nenerally  accented  "don’t 
care"  cases:  Data  representation,  iren.  or  close**  subroutine  expansion 
(but  not  reentrant  or  r.onreent r ar.t  code),  etc.  with  most  languages  it 
is  possible  to  find  rlaces  where  an  override  capability  "idht  be  wanted 
and  EUCLID  is  no  exception.  for  example,  the  language  report  suggests 
that  compilers  should  insert  "spall"  routine  bodies  in  line,  l ut  the 
oroorammer  who  disagrees  with  the  compiler's  judgment  about  whet  is 
small  las  no  ability  to  require  the  rcutin»  to  he  closed. 

The  hardest  pert  of  modify  in'  EUCLID  tc  make  it  co'-oly  with  this 
requirement  is  identifying  all  the  "don’t  care"  cases  which  might  need 
to  be  overridden.  The  cost  of  the  necessary  chames  cannot  b" 
determiner  until  they  are  identified,  but  it  should  not  t>e  too  greet. 


J 
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IJ.  The  user  will  he  able  *c  TS5oci3t>>  compil®  time 
variables  with  pr  n*Jf"  ari<:  - These  will  include  variable?  .Men 
specify  the  ohiect  computer  model  and  other  aspects  of  the 
ohiect  machire  coM  i ourat  ion.  ....F 


FULL ID  has  ro  such  facility. 

Ihi-  necessary  addition  would  he  fairly  easy#  provided  the  feature 
is  ret  too  elaborate.  Ere  tre  currents  on  requirement  14. 


14.  Th®  source  lanciuace  will  permit  the  use  of  ccnoitional 
statements  (®.o.,  case  statements)  dependent  or.  the  object 
environment  a^c  rtr.er  compile  tirre  variables.  I n such  cases 
the  conditional  will  he  evaluated  =t  compile  time  and  only 
th®  selected  pa»-b  will  he  compiled.  ,F 


riTLIh  has  no  conditional  compilation  capability. 

This  facility  can  usually  he  i mp lamented  in  rost  compilers  at  a 
modest  cost,  ♦he  cost  depending  primarily  on  the  source  level 
® l abor a leoes s of  the  facility.  If  there  ar»  any  compilers  which  r®ed  to 
be  c t a rp e d , t^e  charges  usually  can  be  isolated  ir  fh»ir  initial  phases. 


IS.  T d e source  lariouaoe  will  contain  a simple  cirorly 
identifiable  base  or  kernel  which  houses  all  the  power  of  the 
lar-uc.,e.  To  the  extent  possible,  the  base  will  he  r infra.  I 
wi to  each  feature  rrovidin^  a sinole  unioue  capability  not 
c-thrrwise  duplicated  in  the  base.  Thr  choice  of  tie  base 
will  not  retract  from  the  efficiercy,  safety,  or 

jrderstandabi  l ity  of  the  lannteqe.  ....1 


tl’CLlh 

Furthermore , 
with  varirus 
identifiers 
list.  These 


is  o small,  powerful,  lanouane,  as  far  as  it  goes, 
there  seems  tr  he  a concent  of  a kernel  of  the  l ar.gua  je , 
entities  being  described  as  '‘standard",  although  the 
associated  with,  them  do  not  appear  ir  any  reserved  word 
entities  »prf»r  tc  he  extensions  to  the  base  lanouaae. 


fc  U C L I C1 
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16.  Lanouaoe  restrictions  which  are  dependent  only  on  the 
translator  and  not  or  the  object  machine  will  be  specified 
explicitly  in  the  lanoitaoe  definition.  ....P 


A number  of  translator  dependent  limits  — includim  some  of  the 
ores  specifically  mentioned  in  this  reaui recent  — are  rot  fixed  ty  the 
language  report.  However,  minimum*  for  these  limits  are  specified 
(*-.  5°).  It  is  possible  to  ccTnlain  that  at  leas*'  one  of  these  (the 
maximum  number  of  elements  in  a rowerset  —16)  has  been  set  too  low. 

It  is  an  easy  task  to  fix  the***  limits  in  the  li.nguaoe  definition 
and  the  effect  on  most  compilers  wculo  not  he  oreat,  but  — as  for  the 
compiler  defaults  ( reuui remert  II)  --  it  may  not  be  possible  to  control 
compiler  writers  to  prevent  them  from  tr**atinr  the  limits  as  minimum*. 


16.  Lanouaoe  restriction*  which  dro  inherently  dependent 
only  on  the  obiect  environment  will  net  be  built  into  the 
language  definition  nr  any  translator.  ....P* 


this  reouirement  is  basically  satisfied.  It  is  oossitln  to  look  at 
the  low  "limit"  (minimum  maximum)  of  ')(.  elements  in  a rowerset  (p.  5S) 
as  having  been  dictated  by  the  word  si?e  of  a lane  number  nf  existinr 
mini  computers  . 
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13.  The  user  will  he  able  *c  associate  compile  time 
variables  with  programs.  Tb®se  will  include  variables  alien 
snecHy  the  obiect  computer  model  and  other  aspects  of  the 
ohiect  machine  co^t i our at  ion . ....F 


F L!  C L I C has  no  such  facility. 

lit-  necessarv  addition  would  he  fairly  easy,  provided  the  feature 
is  ret  too  elaborate.  See  tre  comments  on  r eo.ui  rement  14. 


14.  Th®  source  lanpuace  will  permit  the  use  of  ccnoitional 
statements  (®.ct.,  case  statements)  depenoent  or.  the  object 
environment  a^c  other  compile  time  variables.  In  such  cases 
the  conditional  will  he  evaluated  *t  compile  time  and  only 
the  selected  pa«-h  will  he  compiled.  ....F 

ritfLIb  has  no  conditional  compilation  capability. 

This  facility  can  usually  he  implemented  in  most  compilers  at  a 
merest  cost,  *h®  cost  beperdino  primarily  on  the  source  level 
elaborateness  of  the  facility.  If  there  ar°  any  compilers  which  n»ef  to 
he  changed,  the  charges  usually  can  be  isolated  in  th®ir  initial  phases. 


75.  The  source  lariouaoe  will  contain  a simple  clearly 
identifiable  base  or  kernel  which  houses  all  the  power  of  the 
lar?ua;e.  To  the  extent  possible,  the  base  will  he  m infra l 
with  each  feature  rrovidir^  a sinole  unioue  capability  not 
otherwise  duplicated  in  the  base.  T*'®  choice  of  tie  base 
will  not  retract  from  the  efficiercy,  safety,  or 
understanaabi  lity  of  the  language.  ....1 


fcl'CLIP 

Furthermore, 
with  various 
ideoti f iers 
list.  These 


is  a small,  powerful,  language,  as  far  as  it  goes, 
there  seems  tr  be  a concept  of  a kernel  nf  the  lar.guaje, 
entities  being  described  as  "standard”,  although  the 
associated  with  them  do  not  appear  ir  any  reserved  word 
entities  appear  tc  he  extensions  to  the  base  lanouape. 


t 
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16.  tannuaoe  restrictions  which  are  dependent  only  on  the 
translator  and  not  or  the  opject  machine  wilt  tc  specified 
explicitly  in  the  lanatraoe  definition.  ,...P 

A number  of  translator  '•erendert  limits  — includim  some  of  the 
ores  specifirallv  mentioned  in  this  reoui recent  — are  rot  fixed  tv  the 
lonnua.-jt'  report.  However,  minimum*  for  these  limits  are  specified 
('•.  5°)  . It  is  tcssibl**  to  complain  that  at  least  one  of  these  (the 
maximum  number  of  elements  ir  a rowerset  ~1A)  has  been  set  too  low. 

If  is  uri  easy  task  to  fix  the**  limits  in  the  Ir.nquaae  definition 
and  the  effect  on  most  compilers  wculo  not  he  oreat,  but  -•  as  for  the 
campiler  defaults  ( reoui res er t 11)  --  it  may  not  be  possible  to  control 
cc^i  i<*r  writers  to  prevent  them  from  treatinn  the  limits  as  minimum*. 


J1 
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J1.  The  language  and  its  translators  ail  l net  impose  rur. 
tine  costs  tor  unneederi  or  unuser’  generality.  They  will  he 
catfcblr  of  producing  efficient  cede  for  all  programs.  ....'! 


So  efficiency  cost  for  unused  features  .......................... U 

Ffficient  code  car  te  produced  ♦or  all  features  .................  I 


R run  is  a clear  lannuane  end  the  designers  have  given  cuite  a bit 
of  corsi  der  ation  to  i mp  l emen*  -<•  t i on  njestions.  There  is  reason  to 
believe  that  a compiler  car  he  1 1 i it  whirl,  would  not  charge  the  usnr  for 
unused  features,  but  there  is  no  compiler  in  existence  at  present  to 
verity  this  te li ef  . 

Tnere  are  some  features  of  F I J ( L I D which  are  cotentially 
inefficient,  and  these  are  acknow  ledger*  ir  the  lanruace  re> ort 
fpp.  3?-3h).  Such  potential  inefficiencies  are  in  almost  any  high-level 
lanauc'e,  an*  netting  rid  nf  them  is  impossible  within  cjrrent 
technology,  at  least  if  the  lannyare  is  to  he  useful.  It  is  th" 
r esnonr ibi l i t v of  the  user  to  learn  thr  inefficiencies  of  the  language 
and  decide  if  the  feature  should  be  avoided. 


* 


J?.  Any  optimizations  performed  by  the  translator  will  net 
change  the  effect  nf  the  program.  ....I1 


This  is  a compiler  recui  ren.ert , not  £ lancusce  reou  i recent , and  is 
thus  not  addressed  by  the  lanoijagr  report. 


J3.  The  source  larcuane  sill  provide  encapsulated  access  to 
machine  ue; endert  hardware  facilities  includiro  machine 
lan-uafie  code  i r$*>r  t i nns . 


.Pt 


« machine  cone  capability  is  define d through  the  use  of  machine 
instructions  in  routines  (procedures  end  functions).  The  routines  can 
be  declared  with  an  inline  attribute,  which  requires  flat  they  be 
expanded  in  line.  Thus  the  user  has  a lull  machine  code  capability,  but 
with  some  clumsiness  involved  if  all  he  wants  is  to  insert  a fe  ,• 
instructions  into  a sinnle  location  in  his  program.  < p.r . 51-57) 

It  would  be  a simrle  job  to  invent  a syntax  which  permits  in-line 
insertions  of  machine  code.  Thtre  .ould  he  almost  nr  cost  to  any 
compiler  teciiuse  the  ahilitv  to  recognize  « nd  romnile  machine  code 
instructions  is  already  present. 


EUCLID 

Peauin'^ent  J4 


J4.  It  will  he  r^ssiKe  within  the  source  language  tc 
specify  the  obiect  presentation  of  ccmoosite  data  structures. 
These  descriptions  will  tr  optional  and  encapsulated  and  will 
be  distinct  from  the  locical  description.  The  user  will  be 
able  to  specify  the  tire/snace  trade-off  to  the  translator. 
If  not  specified,  the  object  renrese  nfat-  ion  will  be  optical 


as  determined  by  the  translator. 

Encapsulated  specification  ot  representation  possible  .......... ,T 

Space/tine  tradeoff  can  bn  specified  ............................ P 


EUCLID  has  a machinr-dcrendent  record  capability,  which  permits  the 
exact  specification  cf  the  positions  of  fields  within  records  (p*.  24). 
otter  data  structures  nay  he  specified  with  the  packed  attrioute,  which 
directs  the  compiler  tc.  conserve  space  at  the  txrense  of  time  (p.  IQ). 
There  is  no  attribute  which  directs  the  compilers  to  generate  the  most 
time-efficient  structure,  however.  lhu*  if  the  compiler's  default  data 
structure  requires  overly  clu""sv  code  lor  some  particular  use,  the 
oroqrasumer  is  forced  to  rely  on  rr;>chine-dependent  records,  ana  these 
sometimes  result  in  inefficient  rnde  «-h<?mse  l ve« . 

It  is  easy  t*  invent  a new  attribute  to  further  refine  the  types  of 
data  layouts  generated  by  the  ccmoiler,  but  the  expense  can  be  moderate 
to  high,  particularly  in  the  code  generator. 


J5.  The  programmer  will  te  able  to  specify  whether  calls  on 
a routine  are  to  have  an  open  or  closed  implementation.  *n 
oper  and  a closed  routine  nf  the  same  description  will  have 


identical  semantics.  ....P 

Ooen/closed  properties  can  he  specified  f’ 

Open  and  closed  versions  have  the  same  semantics  ................  T 


It  is  possible  to  specify  th^t  a routine  is  to  have  an  ooen 
expansion  and  the  language  rerort  specifically  calls  for  no  difference 
in  semantics  between  the  two  tyres  ot  expansion  (op.  51,  54).  It  is  not 
nossible  tn  specify  that  the  routine  must  have  a closed  expansion, 
however . 

It  is  a trivial  tasV  *o  add  a closed  rttribute  to  the  routine 
declarations  and  the  cost  to  comrilere  w'Mild  te  negligible. 


E U C L t r> 
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Extraneous  features 

we  recommend  th;.t  the  following  features  of  FUCLIb,  not  required  by 
the  Tir.^an,  fc»  ke>->t: 

* Strinn  type  (assuming  that  the  Tint  an  requires  only  u 
character  type,  not  a character  strim  tyre). 

* Octal  ant'  hexadecimal  representations  for  numeric 
constants.  T*est  arp  occasionally  useful  and  cost 
very  little.  * binary  capability  might  be  added  a? 
well. 


* The  mod  operator  (remaindering ) . 

* Zone,  wtich  allow?  the  rroirae.rer  to  implement  is  own 
dynamic  storage  allocation  when  desired. 

* The  elseif  clause  of  the  if  statement.  This 
implements  a common  strurture  often  overlooked  in 
other  languages. 

* The  exit  statement.  This  is  a surrogate  for  goto,  tut 
it  has  useful  document?  tier,  attributes. 

* The  numeric  function*:  abs  and  odd. 

* The  numeric-character  conversion  functions  chr  and 
ord . 

* The  successor  and  predecessor  functicns,  succ  and 
pred,  for  use  with  enumeration  types. 


i.e  recommend  that  the  following  features  of  fUCLID,  not  r"d»jired  by 
the  Tinman,  be  deleted; 

* The  storagellnit  and  storageUnitBits  tyres.  Their 

purpose  is  unclear  and  they  are  highly  machine 
dependent . 

* The  signedlnt  arid  unsignedlnt  types.  Panne 

specification  should  he  recurred  of  all  integer  data. 

* Legality  assertions.  These  conflict  with  the  Tinman 
requirement  that  ell  features  be  within  the  staf»  of 
the  art  (requirement  *1). 

* Specification  of  internal  representations.  These  are 
incomplete  and  even  "»ron  j".  for  example,  True  must 
oe  represented  by  t irary  zero  md  False  by  binary  ore, 
exactly  the  reverse  of  the  "natural"  representation  on 
many  computers  . 
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* The  re-mirement  that  fields  in  rachine-dependcnt 
records  must  rot  cverlar.  Tr  remove  this  requirement 
permit*  all  sorts  of  mischief,  hut  the  ability  to  do 
stranrje  thirds  is  one  o4  the  reasons  for  needinrs 
user-defined  record  structures. 

* Restricting  orinters  4o  point  to  dynamically  crested 
variables.  Removing  this  restriction  oiv»s  ud  some 
protection,  hut  thst  loss  is  nMset  by  the  increased 
caDaoi l i ty . 

* Dual  notations  for  field  referencing  and  oemter 
de  re  f e renc  i no . *ultinl«*  notations  lead  to  lack  of 
clarity  in  preoram  listings. 


lr.  addition,  tlfCLID  defines  an  unchecked  type-conversinn  (p.  31). 
This  featur*  is  useful,  eVen  necessary  in  some  cases,  but  it  is 
machine-dependent.  Uses  of  this  feature  should  be  bracketed 
(encapsulated)  by  statements  xhirh  point  out  that  dependence. 
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Summery 

fUCLJO  is  ft  small,  elegant,  language  Designer!  for  writing 
verifiable  system  programs.  ire  desi'^ers  b?<ve  been  riqorouslv  c ji  !eo 
by  those  Dual  'toals  — ver i f i ah  i l i ty  arrt  system  oroor e»m*n i no  — a^d  have 
produced  a scare  lancuaqe,  yet  cne  whicn  is  quite  powerful  within  its 
tinntly  circumscribed  limits.  They  have  also  teen  guided  by 

implemt  nt  fttion  considerations,  >.ith  the  result  that  FUCL10  annears  to  be 
eminently  i rr.  I erne  nt  at  l e . 

We  s?y  "appears  to  be"  because  EUCLID  is  at  present  a naoer 
lanauaor  — there  are  no  known  rrwrilers,  although  at  least  ore  is  oeinq 
developed.  Thus  tnere  is  no  experience  to  back  up  any  of  the  opinions 
“xnressed  in  this  report,  particularly  those  concerriino  efficiercy. 

Amcnc  the  "unusual"  features  reaufred  by  the  Tinman,  EUCLID  has: 

* Strong  tyrinq. 

* A comylete,  regular,  data  definition  facility. 


* A lack  cf  arbitrary  restrictions. 

* Recursive  routines  and  data  structures. 

* Scope  rules  which  nermit  the  scope  cf  allocation  to  be 
larger  than  the  scope  of  access,  bu+  which  can  also 
force  there  to  be  tie  same,  yet  not  the  entire  program. 


* A useable  nninter  mechanism,  olthcuch  crobafclv  "ior<* 
restrictive  than  is  desirable  in  the  DOD  environment. 

* Free  format  of  the  source  program  with  a context 
sensitive  rule  which  permits  omitting  the  statement 
terminator  in  many  cases. 


because  of  its  site  and  conflicts  with  the  two  desiqn  coals,  EUCLID 
lacks  the  following  features,  required  by  the  Tinman: 

* Fixrd  print  and  floating  point  data  types. 

* Statement  labels  and  the  goto  statement. 

* Input /nut put. 

* Exception  handling. 

* Parallel  processing. 

* An  ability  to  define  new  irfix  operators  or  to  extend 
existin’,  operators  to  new  data  tyres. 
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* Special  syntaxes  for  srme  common  control  structures 
(e.o.,  loop  while  and  loop  until). 

* Procedure  exception  parameter  classes. 


It  is  difficult  to  beep  4rom  being  overly  enthusiastic  about 
LUCLir>.  The  designers  ►avf  produced  a powerful,  elenant,  lanouape.  Of 
course,  it  is  to  4e  e*p“cted  that  prot lems  will  arise  as  the  language  is 
implemented,  but  we  do  rot  lelieve  that  they  will  be  irajcr.  As 
me nh i p^ed  above,  many  cf  the  »"issinq  features  have  bfen  left  out  because 
they  ccrflict  with  t*>e  two  basic  ^esior  goals.  I/O  and  fixed  point  and 
flocitirp  point  ty^es  are  not  reedea  ir  system  rrogramminr,  for  example. 
* lar;e  number  of  these  rrissipp  features  could  be  adoed  to  the  language 
with  little  difficulty,  as  they  rrftsent  compilinc  problems  which  ire 
-»ell  understood.  Others  — parallel  processing  and  infix  operator 
definition,  for  example  — are  rot  so  well  understood  (at  least  as  far 
as  agreeing  on  a "best"  set  of  features  or  syntax)  and  could  cause 
problems.  Apv  attempt  to  enlarge  EUCL1P  to  briny  it  up  to  the  Tinman 
requi rerents  will  doubtlessly  result  in  a clumsier  language,  and  one  at 
odus  with  FllCLir  »S  ocals.  (For  s reason  we  suooes*  that  the 
verification  featurrs  of  El'CLTP  be  dropped.  A Tinman-sized  lanojage 
will  have  features  which  make  verification  impossible  within  the  state 
of  the  art.)  Yet  it  appears  that,  oiven  such  a solid  basis,  if  such  an 
enlargement  were  done  with  great  care  there  is  a good  chance  rhat  an 
appropriate  realization  of  the  Tinman  would  result. 
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introduction 

T"ir,  report  ives  r coni  prison  c t tvc  lanetiaoe  JOVIAL  J d ' t (.  the 
Ti-Td*”  laniuj'Te  re  ;ui  reern  t s (i/epertmmt  rf  Defense  ‘'euui  re T,ert  s lor 
•i  i r.h  ( r '.e  r forjujter  h ro  - r f>mtr  i no  | rir^i'adf,  "linTan"  - 1 ’!nrc^  1^70, 

Sectior  iv).  For  ft**  riTT**'  f1  this  cn^rar  i si)p , J ">  V T A l J3'<  ^ s 
cpr<rirrs'1  to  L»  e f i n e ::  hv: 

JOVIAL  /J7P  L *>n-u3sif  S c i 1 i CJj  * icn  r »terr icr  * 

Sotted,  Ire. 
faltnam,  ^hss. 
heewment  <?’’A4-4.? 

July  1 «•  t 'j 


T i *-  -r  =*  n contains  7°  l&noucoe  rec-u  i recent  s . This  report  coi;  ores 
JwVdl  J7t-  to  each  rnpui  rerrrot  individually. 

It  .1  re  oij-*  rrner  t is  totally  satisfice,  the  acce^pinyion  text  is  a 
« u t ns  a r y 

of  the  particular  nee h anise  used. 

( 'ccor  ic  ti«  l ly  no  text  i s neeclen  it  a ren  uirermt  is  totally  so  fist  ieo.) 

It  ,1  requirement  is  net  totally  satisfied, 

the  te»t  consists  ot  n sjmir&ry  of  the  shortco^incs  me  such  iters  as 
tti**  sm::e  of  the  change s necessary  to  Fully  -ee*  the  rrcjui  r>’ -ent 

*n<*  tr**  i'".."'Ct  n I those  char.,'?r  00  existing  in.- I err  en  t at  i ons  . 

C'd  Tirran  rejuirerert  r eoirs  with  an  introductory  caraorart. 

These  T.r».nranhs  me  reproduced  in  t*"is  report. 

In  if?r  y cases  they  are  followed  ! y several  simile-line  ruroirar  i*s  of 
features  in  the  r r e a ot  the  require  rent. 

Usually  these  are  features  wKicn  are  specifically  called  fer  in  t h.  • 
re.-u  i re*  e nt . 

a feature  enclose^  ir  rar  e r t *■  r s»  r , hov.*v'’r,  if  cnr  vhict  the  reviewers 
thrjo't  v<'*sicly  desiratlr,  eve*-  th;>urh  not  called  tor  in  tve 
require "ent. 

:>v’b(  Is  placed  beside  th*  irtroructrry  paragraph  and  t^*  intividial 
fpatuf'S 

inoicrte  the  oecrre  to  which  t*-p  requirement  or  fmfure  is 

satisfied  tv  the  larouaqe. 

The  symqls  and  their  meaninns  arc: 

T - Tot  - l l y satisfiea 

p - Partially  satisfies 

f - Fails  (not  satisfied  at  all) 

U - unclear  from  the  ac c u*pnt a t i on 
'’4  - A l tost  totally  satisfied 
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p - - only  r l i - h 1 1 > satisfied 


N / A - Nut  applicable  (i/eer4  onlv  tor  indivi  r,u  > I 
t e .'tv:r  e 1 the  rff>uire»ert 

if  not  satisfied  -i t alt) 


f T he  s v t>  ''Is  | , (•»  , r 

nd  ( - 

* i 1 1 r 

f t er. 

a r “ 

stated  in  one  of  the 

tor  n.  s 

"There 

-ill 

"A  l l ...  ",  even  t ViKf 

r n l y 

T or  f 

arc 

cases.) 


! e i.  sen  vith  re ouir errors  . tic” 
he  nr..."  r r 

technically  a r p l i r.  f rl  r -in  these 


1 h e report  concludes  *ith  two  sjTTeries. 

tea  turns  of 

JOVIAL  J5n  •' hich  are  extranr^uD  o tinman  and 
of  retfinin  each  rf  the?,  Or  secern  is  of 
3 whol*>  ..no  tie  desirability  of  t e n i f y i n - . it 
with  the  f iman  reaui regents . 


The  first  is  of 

the  desirability 
the  lanuuane  af 
t r trine  in  into 


t bt 


l i re 


1 

! 


i 
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jrn'in  j7-’ 

A 1 


AT.  the  lanouaoe  will  te  typed.  The  tyre  (or  mode)  of  all 
variables,  cnrconerts  of  composite  cats  structures, 
«x ’ r ess  ions , operations,  and  r?ra»etrrs  will  be  neterninable 
at  ro-p'ilp  time  anr  unalterable  at  run  tin®.  Tie  lanouaoe 
will  require  that  the  tyf  e of  eac1’  variable  end  component  of 
con-osite  date  structure*  *e  explicitly  specified  ir  the 
*;  o j r r “ r>  r o o r a if  s . 


JCV 1 *L / J 

<n 

require?  that 

the  *y(f  cf  each  varic 

u 

Ic, 

da  1-d 

table. 

array,  etc. 

oe 

explicitly 

specified  rv  ttu-  user  c 

t 

the 

t i me 

b t c 

j ol  t n 

dt  f i n i t ico  . 

All 

items  must 

ue  nee  lured  before  ur 

e 

. 

1 h c 

type 

0* 

operations  c 

r d 

expressions 

are  not  specified  cy 

t he 

usr  r. 

tut  are 

de ter-irar  lo  at  compile  tire.  Tie  tyi  e of  any  iter  carrot  be  charge, 
rur  -t  i*r.  i;erce  J7P  ""rets  ttis  rnuirr  rent  . (pp-  4-i,  4-14) 

f.  < ccrflict  with  other  rroui  rei  ents  . 


A/.  The  Uinauaoe  .ill  provide  data  types  for  integer,  real 
Tf leaf  inn  noint  and  fixed  print),  boolean  and  character  and 
will  provide  arrays  (i.e.,  composite  data  structures  with 
indexable  components  o4  hoftonerpcus  type)  and  records  (i.e., 
com.iorite  data  structures  u i ♦‘h  labeled  cor  r.-cnent  s of 
heterogeneous  type)  as  tyre  reneraters.  ....T 

Into  o r ........T 

Floatin';  Point  .T 

Fixed  Point  ..............T 

buolran  ............. ...T 

Character  Strinn  T 

Arravs  ................................................. ......... t 

Records  T 


J 3 F allows  signed  or  unsigned  integers,  *"inclr  or  ocuhle  precision 
floating  point  "umbers,  fixed  mint  numbers,  bit  strims  O-oolean 
variables',  character  strings,  arrays,  and  tables  (records),  as  built-in 
fata  types.  it  therefore  fully  meets  this  regui  rement . (p.  1-?, 
Section  c). 

no  conflict  with  ft*  er  requi rement s . 


A?.  The  source  language  '-ill  require  oloual  (to  a scope) 
see  c i f i c at  ior  ot  the  (recitin'*  for  floatin';  point  arithmetic 


,nvi»i  j m 
1 e *■  j i r <*"  en  t M 


ir,d  will  permit 
variables.  T r,  i s 
•na  ■»  i •rit if  f r e c i s i on 
r.  i ni  ; v"  T r c i s i Of' 


rreci'icn  r-.  oecifiration  for  i o<t  i v idu«  l 
sner i f i ca t ’ ?n  will  he  interpreted  ns  th® 
r»u'jireri  hv  the  *ronrri!n  lo^ic  and  the 
to  he  sw< ported  ty  t he  oliect  coce. 


f-l;.'  >1  arithmetic  nrecision  sr  e c i t i c a t i on  mandatory  . 
Individual  variable  precision  sre  r •»  f i r at  i or  permitted 


j I' 1 dors  not  re:uire  that  t»  ♦ rrecis ion  ter  ? 1 1 computations  to  he 
. r r tor  red  in  floatin'  print  .arithmetic  or-  declared  qlo bally  tor  any 
scone.  Dnlv  individual  spec  i f i Cc  t i on  of  simlr  or  rouble  precision 
floetino  point  variables  is  n®  r~ i 1 1 eel . The  actual  orcririon  is 
icrrc-'-i't  moo  tt  • worn  size  < f ph«  coT-uter  ?no  its  re:  resent  at i on . 
The  ; rccirion  s',  critic  a tinn  fur  fixer  point  rubbers  is  a ! sr  nacriine 
de.:  eriuc  nt  and  is  r o*  controlled  rv  *he  irer.  (rp.  1-5,  1-15,  1-14,  d -0 , 
?-1  J,  >-1  1,  6-2) 

To  -nrrt  this  requirement  the  J7.'  larctiaqt  will  h :vff  to  hr  -oditied 
to  rrjuire  t^at  recision  f»r  all  II  cation  point  arithmetic  he  declared 
dlohally.  furtlr r"crp,  it  shiulu  permit  explicit  r r tcision 
specification  for  individual  f Ira  tiro  rnd  fixed  po^nt  varii'der  rather 
than  mpicinm  them  haruware  vnrd-siz®  dependent  as  at  present. 

Ir-r  l pment  at  i on  cf  tfsec  rh-noes  will  affect  all  existine 
i i)'' l er;  rnt  at  i ons  . F> press  ion  irocrssin  , d'tc  definition,  a 1 1 r cat  ion 
nroceurer,  and  the  syntax  checkin'-  mechanism  v-.ill  hove  to  be  mp<4ifiel. 


41  4 . Fixe-4  rri't  numbers  .ill  ‘ e tr°ated  as  exact  ouantities 
whirr  have  n ranpe  ar.u  a fractional  steo  size  wnich  are 
detrr  mined  by  t ► e user  at  corr  i l 11  timp.  Scale  factor 
TardneT.ent  will  hr  done  by  the  r.nir.j,  i le  r . ...,D 

Treated  as  exflct  nuan*-ities  d 

Pan -e  and  st®p  size  determine  a af  fertile  time  F 

Seel  i n ij  handled  automatically  ........7 


Most  representations  for  -fixed  ooint  numbers  do  not  permit  exact 
representation  nt  many  decimal  fractions.  eenre,  ii  JOVI  * L / J .1 1 literal 
value  "ay  not  remote  its  true  dcci-ral  value  hut  rather  an 
i mp  l pner*t  at  i or -dir  endept  : T'  rnximeticn  to  itr  true  value  in  the  set  •>  l 
< F I X E I c»)>  values.  The  rannp  and  step  size  for  Mved  value  variables 
err  not  s;  tn  fief  Iv  the  user  either.  Fcaliru  is  handled  nut  ots  t i c a 1 1 v . 
Ci  . 1-14,  2-1 1 .) 

the  i-xact  r •• -r  es®nt  at  inn  of  a decimal  nutter  into  l inary  ir  a 
practical  i mnos  s i h i l i t v tor  existing  tv  ms  ct  coirrutrrs.  lowever,  "ore 


J r>  \i  1 A L J » i 
p e u i r e t ? r t * 4 


visibility  cart  be  allowed  the  user  t.  y rrrvi'Mn  ; truncation  anH  roundin'.' 
routines  (e.e.,  round  ur  , round  ^oun,  round  oven,  r tr.)  in  rt-c  lanjmr 
litrnr>.  Further ®ore,  the  Ispruane  «•  hou  I d oer Tit  user  specification  of 
the  level  of  precision  for  these  numbers.  f anr,e  anH  step  s i 7 c should 
also  he  explicitly  specified  in  the  lamuane  syrfay  lor  fixer  Doint 
variable  declarations. 

T • .•  I ement  o t i cr  of  these  charter  in  the  lir.juaqe  features  will  ^ ive 
some  ircact  on  all  existing  compilers  in  the  areas  of  svntr-x  analysis, 
library  routines,  storage  r,  1 1 r>c  a t i or  , etc. 


a > . r^aracter  sets  v i l l he  treated  as  any  other  enumeration 
fy'  ■=■ . . . . . t 

New  :efs  car  he  defined  as  er.umer  at  ion  types  ....................  f 

Asr»i  ,.nd  EBCDIC  are  provided  F 

CCcrversion  capability  hetweer  sets  is  avaitaole)  V/h 

t 

J il  does  not  alio*  the  user  to  si  erify  and  enumerate  Ms  ovo 
character  set.  The  user  must  us"  the  standard  larrjuaoe-c  ef  inti 
character  set  ccnMstino  o t ?.  f jr~<*r  c ~ s e alphabetic  c b a ® v c t e r r , h h •* 
jecim.il  Mpits,  and  1 nrecial  characters.  The  nrovirion  for  ASCII  or 
EPdlC  cone  for  toe  character  set  and  conversion  between  tw  > rets  of 
codes  is  not  controlled  hv  toe  user  and  is  completely  hardware  and 
installation  '■'eperdent . Hence,  J7r  ^ces  not  meet  tMs  r eoui  rement . 
( r o . - c , <?-}.) 

To  meet  this  reoui  reboot  f p I *n.jt?ane  must  provide  for  status 
variables  and  allow  enumeration  of  character  sets  refined  by  the  user. 
Th°  library  must  support  conversion  routines  between  ASCII  ,.rd  fhChIC 
wr.  i c h must  te  available  to  the  user.  The  user  orcnrar  should  than  be 
alloyed  tr  use  the  user  defined  character  set. 


It  lementatior  - f the*e  chur.ie*  in  the  Ifnouaoe  -.ill  have  a m.o  i o r 
impact  on  all  existing  implementations.  The  entire  lexical  and  syntax 
analysis  chases  ot  the  compiler  fstrinn  nr  ari  r u la  t icr , comments  etc.) 
will  h;  vp  tc  be  modified. 


A (i . Tre  lannueae  will  require  user  specification  of  th* 
nu"t»r  of  dirrorirns,  the  r?roe  of  subscript  values  for  each 
dicersico,  and  tyre  o4  fact  arr»y  com* onent . The  numter  of 
dip.ersions,  tve  type  arw  tie  lt*er  subscript  bcund  will  hp 
de  t *■  r ■*  i rat  l e a4  c«rrile  ti"e.  Tr«  upi  er  sutscrirt  I once  will 


mil  i iumI 
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It*  u l>Tr  in?vl  » r.  t entry  to  lit*  ;.rny  a l l certify  jrcri'.  ....hr 

N j’itr  ''1  d.  i re  ns i a r s is  fiver*  st  respite  ti-r  .............I 

T>pr  is  f i > e >.  ft  crnrilr  t i r»;<  . I 

l'-  ,.t  r sjoscr  i.- 1 heund  is  five-,  it  cot  i Ip  tim  ...........T 

IV:  t rubsrri-i  bound  is  fixtc  :<f  serr  e entry  F 

f'Ul'crirty  crly  irtpners  <r  fron  or;  er  urrep at  irr  tyre  I 

Subsernts  v i l L te  f r or  u cont  i oucus  ranee  T 


1 r.  *’  J5‘  larrisi’t'  sn.c  c i f i c at  i nns  require  rt-at  the  user  si  reify  r,oe, 
two  cr  three  dimensions  for  an  array  at  com;ilp  tii'p.  the  type  r f t h «• 
array  t r t ■’xeo  at  ton  i I e tine.  Alt  elf-rents  of  the  .-may  are  require-4 
tc.  I r * mod  pop  -iljs  in  tyre.  lv»'  Ifineua-f  f u tore  t i c a 1 1 y fives,  the  lower 
bound  t t ‘he  brr.’'  tc  f.  The  usrr  must  srecify  the  upper  t chop  of  toe 

array  >t  coroi  l " tine  oj  a rnsitiv®  irterer  constant . The  u|  r»-r  bound 

is  not  tvalueLlc  at  store  entry  tine.  (Section  4.4.) 

Ti  m-et  this  rn-'jirnnprt  the  lareumc  will  have  to  alloy,  thr  use  of 
expressions  in  ji  per  sjtsrrirtr  «.hirh  evaluate  to  •*  positive  irttgtr  at 
seme  entry  tirn“.  The  arrays  will  t*-pn  have  tr  be  allocated  a* 

oxecutim  ti«f  instead  r f it  reunite  tine  at  ii  prefer, tly  rone  in  th" 

existin',  in;  l err  mt  at  ior-s  . 


A7.  The  Ian: j;ce  will  permit  rererds  to  have  alternative 
structures,  each  ef  y 1 ul  is  tivet,  at  compile  tire.  The  nar.e 
and  tyi  o of  each  record  fc'ccrr-t  v ill  t r srecifirc  by  tK'* 


user  at  co nr iln  tine.  ..  ..d 

Alftrn-tive  structures  fer  reerret  «.rr  possible  ...........T 

r i r c r i r.  i na  t ion  condition  nay  I f anv  Footean  exrression  ,.f 


I 


J ."  V i a L / j 7 q rroviries  cm  OVERLAY  feature  which  allows  the  user  tr 
specify  not  only  the  records  or  variables  vbirh  ran  overlap  each  other, 
t .it  oIm  the  na  re;,  nt  variables,  arrays  end  records  which  are  assigned 
successive  sterf  e locations  ir  cere.  (or  example,  OVIRLAY  A,F*,C  = F1 
will  a l l o ' allocation  of  A,  d,  ard  r to  I f continuous,  one  after 
another,  .r.il<  t tie  s.inr  tine  FI  will  be  allocated  startim.  at  the 
Incatic"  ••here  f w.as  allocated.  Rich  variable  will  be  available  to  the 
user  at  run  tine.  (owevc-r,  the  l anr-unf  * ores  not  rrnvide  for  « Loolein 
extras* for  to  hr  use*1  ns  the  c.  i s c r i ni  re  t i nn  enrditior-  to  te  used  for 
field  ft  lectio*-.  hence  it  does  rot  ivf  t that  rorticn  of  the 
r ••  ; 1 1 i r e •■  e nt . (Fectior  4 .(.) 

Tv,  "ret  this  reuuirerert  the  Ir-n'uiaoe  syntax  will  hive  to  bp 
nc ''idler  to  all*  selection  rf  '-vrrlrirt  fields  after  evaluation  a 
ocolem  p*  pr  p*  s i o'- . The  result  cf  f*r  evaluation  will  reterrine  which 
of  the  • vc  r la  id  ♦ it  l c*-  is  to  te  selected  a no  returned  to  the  user. 


J r,  • 1 1 l j * ‘ 

Kfuttctpr  f • " 


i ' <}  tjristin-i  cct^ilcrs  r>c  r't  ;r<»v  i't  such  facility  a nr*  w i l l n.jvr 
tc  If  a^cificd  fr  oCCC'cCJ'tf  this  ch«^i,e  ir;  the  I rnrun.it . 
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PI.  C ssi  •'tnmerl  and  retererce  oneratri'Mi  will  te  automj.  t i c ?<  1 1 y 
definec.  for  ell  cat?*  typer  vMrh  do  not  manaqe  their  nat«* 
st  The  5‘ssi  cnfrent  rrer^tior  .ill  rcrrit  any  value  of  a 

fiver,  tyre  t'  tf  assigned  tr  c.  variable,  array,  tr  record 
cne ->c  nmt  of  tlrt  tv:e  cr  :*  «•,  union  tyre  cortainina  tfat 


tyro.  -eftrence  will  retriev*  t*e  lest  assigned  value.  . ...P 

Autcnr  t i ca  1 1 v ~effnpo  for  my  tyre  (e*r<»r  t ...1  i 

£yr  i l..!le  tor  individual  ctmcnenfr.  r 

( A ss  i crimen t *nw  r “fererre  via  functions)  ........................T 

'ssinpment  and  reference  orer<:.tirns  are  defined  for  the  tuilt-in 


Jrta  tyres  in  J’P.  Valuer  fer  ? built-in  tvpe  cor  be  assi»inen  to  the 
varictle,  pseudo  variable,  array  cononeot  nr  record  component  '>1  that 
tyre.  Addit ionn 1 1 v,  cinvtrsiof  ? are  allowed  to  assion  values  of  a 
different  type  to  a target  of  built-in  data  tyte.  The  assigned  values 
can  I f referenced  by  urine  the  name  of  th“  target.  however,  the 
assit’r  r eot  operation  is  not  defined  for  conformable  arrays  arn  records 
as  a *>hc  l r . (Sectior  5 . ? . ) 

ko  rontlict  with  othrr  requirements. 


Vt.  Ite  source  larcuaoe  will  have  a ►uiitt-in  operation  which 
car  be  used  to  eoirpare  cry  two  oata  obiecte  (regardless  cf 
tynr-t  for  identity.  ....f 


j d ' provides  for  = s i on  which 
objects  (reuarrilcss  of  typp)  for 
compe r i sons  are  node  for  eoualify. 
comparison  r*s  necessary.  (Section 


ten  be  use'f  for  comnarinn  twe  data 
identity.  Ionic a l and  not  bit  ty  bit 
Conversions  are.  performed  before 
7.) 


r ■>  conflict  *it»  other  reou  l rrmer.tr  . 


Pi.  Relational  operations  will  he  automatically  defined  for 


numeric  data  and  all  tyres  defined  by  enumeration. 

Pu’lt-in  for  <11  numeric  anu  enumeration  tyres  .1 

Omerinq  can  be  inhibited  when  desire^  . r 

j'l  provide-  for  all  si*  relational  ooentnrs  fr.  7-1?)  for 


c i.  non  r i son  of  numeric  data.  now  ever,  since  the  lan.uiaqe  d-,ps  nr.t  allow 


j ;>  v \ t i t r- 

de-jui  ep->  € f't  r 7 


1 5 / r i«  ti'  eii  aot«  or  status  v;.ri.fMfS,  ♦!  <»se  cperPtoes  :ir*  net  defined 
\ ,x  •',,.iirrrat»,c  i’i* t i*  rr  user  deMerc*  de*n.  ir ,r  t*<?  se'>t  reason,  no 
iiect  iiimT  i5  r>viii  t aM*>  i *>  the  Irn-im.ie  t,  irhilit  or/u-rir.q  of  oatr;. 

t«  inert  this  rpquirerert  the  Jan^ua  if  deffriticn  will  have  tn  !>e 
ntpnrcr  to  nnviiif  tor  jsrr  definition  it  n*»w  det?  type*;  :n,1  status 
variables.  Trier*  lanouauc  rer hani  sms  « houln  hr  provided  to  p'^'entc 
d.-**a  cither  or  erdereo  or  uncroerer!  pay. 

£ n c»  i o r mod i f i cat  i on  to  e x i S t i r-  ir.ir  lemert  rtions  * i 1 1 tc  ''f  cesury 
♦ *>  jCfifToajrp  these  chenoes  i '■  td<e  l»n  uaoe  oe  1 in  i t ion . Type  checkin 
'pciir'vrs,  syntax  anulyirr,  dictionary  or.i  cr^e  eeneration  rhasr*  will 
t ® a 1 1 c c.  t e n . 


n4.  The  built-in  arithmetic  operation*  will  me  I'n’e: 
addition,  subtraction,  mu  1 1 i r l i c a t i nr  , div/isim  (with  a r“*l 
recrlt*,  enponcnt  iaticn,  inte  °r  division  (witt  integer  r~  r 
liv'd  • oint  arguments  ind  rer;.  i 'He  r T , end  nr  :nti')r.  ....*-♦ 

Addition  T 

bu*  tract* or  ..................I 

*\i  It  i r I i c*t  ion  . T 

''iviiim  pith  *,eal  result  

x *'ic,rp"t  i at  ion  . . . . T 

Integer  and  tirea  rcint  division  with  rrmiinder  .................  F 

Neiotim  ........................................ 


'•  * ft  »se  arithmetic  operations,  J'-P  provider.  *or  nil  nl  ’hem  exc*ot 
intp^fvr  livisicn  with  remainder.  (Sections  ?.<?«?,  f . 1 . ) 

1 *•  t InneuoQe  syntax  will  have  to  be  modified  to  provide  for  inteuer 
division  with  r rerai  r'der.  Ttr  user  should  he  rdle  to  spec  if  y .* 
I oration  ,h<*re  the  remainder  can  be  store'*. 

T‘iis  charqe  -ill  lave  a miri-nl  i-*  -,ct  • »•  < r existing  c'lr^ilprs  ir 
the  areas  rf  expression  frrrtssirn  aro  svnfax  cheriino. 


t . Arithmetic  ano  assinnrent  operations  rn  data  which  are 
within  ♦hr  eonye  s ■ -e  c i f i c a t i nns  of  the  r-rorran  will  rvrr 
truncate  the  most  « i mi f i c inf  dieits  of  a numeric  quantity. 

r rue-dire  ill  l.  ? V S I r on  the  le  ,st 

h:r  ioff jors 
l e yoral  the 


Truncation  » - d 

sinnificm*  fi  iitr  ard  will  -ever  h®  implicit 
and  fixer!  point  nur'ers.  lmr  licit  rourfirir 


a j i r o*en+  r- r. 


3 r e r i * i c !.* 
nut  v rr  r . 


floatin''  mint 


\ e w r f r r>  ff.  the  left  4 : ’ r u.'  f ? . i t h i n r o n n e ................ ...»...t 

Newer  on  the  riof.*  frr  inteoer  uni  fixed  pn’nt  ..................  f 

Itrlicit  floe  tint?  roir.t  roun'in-  hevrrd  precision  alloweu  F 

(Rur.  tire  rh*c>s  car.  le  evridr")  ............................  ....'</ a 


J ir  e?  nr  t spec  if v ruler 
i'll  Ipm  r-t.'t  ion  >'e.  ermcnt  (r.  7“’’ ) . 
trjnciitior  .ill  tale  place  only 
rrtci  fuct  ims  stair  that  for 


tor  truncation  and  lf=vrs  f ►,»' 
Therefore  there  is  oc  Juar+ntee  that 
cn  tne  riohl.  Moreover,  th- 
f i x e rl  mint  r o<r  | ut  at  i i n , implicit 


; l v t 1 i ICcl  1 i • lb  M f t I T l tM  I l?r  I I X ' lit  l 1 'li’J  l I l.  I l 

trunc'ticn  of  rrecisior  tits  rn  ft?  ri  <fit  "cy  occur  ( i . 7-Ui).  Fv*n  the 
floitio.  foint  rouodioj  tor  loth  sirrl<>  rrprisien  ant  uout  le  precision 
nyirhtfr.  i * i l p* nr  t at  i or;  de r eoceot . < er.ce  the  lan'uiaqe  cotjletely 

fails  t <>  i.*®tt  this  requirement. 

The  lancniai'e  specifications  »-toulh  hr  modified  to  rr^jirr  oil 
trurcatior  to  tehe  rl?re  or.  t^r  ri.ott  sr.'  with  warninr  to  the  user.  The 
orecisicn  sue  ri  f i isti  "r  for  fixes  and  floatin'-  poiot  number  should  be 
all<o,e-'  to  tne  u«pr.  The  lamuare  should  rern.it  iirnlicit  rminjinn 
beyond  trie  precision  specified  b w t^e  uit. 

These  changes  in  the  lamuaut  will  reouire  minimcl  charges  in  thw 
existin.-  corrilers.  Most  exi«tinn  irrr  l enent  at  i ens  attempt  truncations 
from  the  left.  The  areas  affected  will  he  data  declarations,  expression 
■to cession,  and  rm-time  d i aor.ost  i cs  . 


The  built-in  Fnol»nn  operation*;  will  include 
"or",  "not",  ar’1  "xor".  The  operations  "ano"  and 
sc?,  tars  will  he  evaluate^  in  short  rircuit  mode. 


..  ...  t 


Shor t -circuit 

'h'-rt-rircuit 


nr  rmi  t «• 
w o o l e a n 


J ■>•■  nrovidcs  for  />ND,  op,  hOT  and  XOh  nnolean  operators.  Tt 
♦ **  hijt  does  not  require,  the  short  circuit  evaluation  of  there 
an  operators.  in.  7-14)- 


fn.  7-14). 


H ’no l eon  operutrrs.  T 
circuit  evaluation  of  ther< 


n<*et  the  reoui  re.opnt  a minimal  c^anne  in  the  lenqwaqe  definition 
..ill  r vr  to  h»  rarie  to  require  r.hrrt  circuit  evaluation  of  Hoolean 
expressions.  It  »ill  have  »ir.  ieal  effect  on  those  implement* tiros  of 
tie  l-nounie  «(Mcn  d0  not  evaluate  molean  expressions  in  short  circuit 


J 0 V I Ml  J v 
??ru  i r t n < 


t 


r:7.  I *■  e source  l»n;Hidoe  vill  iormif  scalar  operations  arc? 
assi  n^ent  on  cn"  f orrrad  I e arrays  and  will  ;erptif  u.xta 
tr  f^rs  between  records  or  arrays  of  identical  lorical 

ore. 

SC.’lur  operations  on  nrravs  ......  ,x 

assi  -nop-t  between  records  ant  arrays  of  corf orrat le  type  F 

Tfc  lamudie  definition  does  not  specify  that  scalar  ooeraficns  io.1 
assinnr.tr  t arc  pterrri  ssit  le  cn  crpfnrm.it,  le  arrays,  nor  does  it  a l lea  data 
transfers  hetweer.  arrays  and  record  of  identical  Icriral  structure.  Ary 
sjen  data  transfers  nr  scalar  c per  at  iors  between  cor  f or’dl-le  .may  and 
record  structures  are,  therefore,  i op  l err  ent  at  i cn  dependent. 
(Sectiors  4.3,  I> . r . > 

Tic  scalar  operations  t<r  addition,  siibt  ra  c t i c-r  aol  lojic-l 

CPfparisor  can  F't  aoded  to  the  lanauaoe  definition  fer  con  f or  nap  l r 
arrays.  The  . ssi --in went  operation  can  he  extended  to  allc*  data  transfer 

between  cor f or'ml  le  records  a no  rmays  . -'ut  the  extension  of 

•njlf  ini  i cation  and  division  r-reraf  ions  tc  corforirat  le  srravs  say  he 
Tteamn  'less. 

tore  of  tH*»  existido  implementation*  nay  have  to  le  sonified  f; 
sjeoort  tF.is  eyteraed  definition  of  scalar  operator'  for  >rr.iys  and 
r e c o r e. r . 


i J» . There  will  fc»  no  implicit  tym  conversions  hut  no 
ccnvrrsion  operation  will  Fe  reouired  when  tKe  type  of  an 
actual  parameter  is  a com  t itue-'t  of  a unior  tyre  which  is 
tnr  formal  r,<:ro”fter.  Tfe  larou.v'e  will  prnvioe  exrlicit 
conversion  operations  anom  integer,  fixed  roint  and  floatim 
ncirt  data,  oetwter  tfe  otject  r err e * ent a t ion  of  rushers  and 
their  represent  at i c ns  os  characters,  and  between  fixed  min* 


scale  f actors  . . . . . » 

To  imrlic.it  conversions  ? 

fwf  licit  between  intere*-,  fixed  point,  ami  floatin'.)  point  .......f 

r x! licit  between  fined  print  sc^le  factors  r 

ffxflir.it  bpfwfer  irteoer  arr  rnelean)  f 

(f*~l  icit  betwrrn  integer  and  »ruirxra^eil  types)  .................  f 

(Fx,  licit  between  "ifferent  p-u^era^ed  tyros)  .f 


i 


w 


j o v i n J3«- 

Reoui  r*"-prit  P* 
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J if  -« l lev?  illicit  conversions  infcc.pr,  fi  xeo  mint  and 

fire*  in  mint  n inters  and  permits  mixed  note  srith'iPtK. 

l-'  -rovine  f :>r  "xrlicit  conversion',  4rc«  toe  d a t a tyjp  to  .mother 
rr>e  lao>'uaoe  definition  will  have  tc  he  modified,  f-uilt-in  functions  or 
other  lijn'Miane  textures  will  have  tc.  re  provided  to  nerforv  **xplicit 
conversions  from  c<ne  tvre  ol  data  to  finort-pr.  Similar  functions  will 
also  ‘-e  required  to  handle  * i»eo  point  scale  farters. 

.?  >rf  l n-entnt  i rn  of  these  capabilities  -ill  affect  all  '•xistina 
implementations.  *':aior  cbnmes  will  have  to  te  made  in  tne  areas,  of 
“xnression  proce^sin-.;  assignment  and  svntnx  checkin'!. 


a9.  Fvnlicit  conversion  operations  will  not  be  required 
between  numerical  ranges.  Tt°rp  will  fe  a run  time  exception 
condition  when  ary  irteoer  nr  fixed  [pint  value  is 
truncated.  . . . .P 

Implicit  conversion  between  raoues  ...* 

Fxcp-tion  condition  or.  intecer  and  fixed  noint  truncation  I 


J3f  ones  not  allow  rand'*  specification  lor  variable*.  It  do-s, 
however,  require  an  errer  condition  to  be  raised  if  the  value  of  an 
inteqpr  or  fixed  constant  exceeds  the  value  that  can  be  stored  in  the 
coeput'r  words  arsiqned  to  store  that  value  (usually  an  inteoral  number 
of  full  computer  cm's  is  nssicnerO.  <rections  2.2. 1.1,  3.1.1#  1.1. 0 

i(ic  lanruaoe  mod  i f i r at  i or  tc  provide  for  user  sr ee i f i ca t i on  of 
ranee  of  variables  is  necessary.  explicit  conversion  operations  tetw«»en 
rarues  will  not  he  reouired. 

This  lanqufioc  mrdificuticn  i.ill  have  minimal  impact  on  existinq 
i mp  lement  at  i ms  . 


PIT.  Ihe  bare  lannuanc  will  provide  operations  allowing 
programs  to  interact  with  fifes,  channels,  ur  d«*vic?r, 
includin'!  terminals.  These  operations  will  permit  sen'ino 
and  receiving  both  data  and  control  information,  will  enable 
crc’rans  to  dynamically  assign  and  reassin*  I/O  ufvices,  will 
provide  user  control  for  excertion  conditions#  ard  will  not 


be  installation  rieperdent.  ...,t 

S^ndind  and  receivinr  of  d;.t?:  f 





Pecui  recent 


br*unnj  an  i receivino  of  control  information  r 

hvonr-ic  device  assiarupnt-  r 

U^r  fvccction  condition  control  < 

Inst  - 1 lation  i nderendence  ..t 

(Cat  a tornibttirq  capability)  ....r 

(5 ranine  and  writ  in  i ot  hit  strings)  f 

J 'h  -'01.5  riot  provide  for  \>r  features.  ^(.nce  there  arc  no  l<irri#v 
const  ructs  «»•  ich  a 1 1 ok  rrorrur  interacM.-r  v-ith  files,  channels,  c.pvice- 
or  terminals.  ho  car  ability  to  read  or  «ri.tp  data  on  i/O  ^vir?5  i r. 
availit  le  anH  re  static  or  dynrmir  assinnrrnt  of  I/O  nev  i cpr»  i ' 
oermissible.  The  user  can  not  control  exception  conditions  either.  *11 
r.f  truer  features  are  irp  l pspnt  at  ien-dependent  . 

A systematic,  standardized  set  of  I/O  statements  need*  to  te 
detirpd  *->r  toe  lanouaoe  tr  allow  it  t0  perform  pach  of  fie  functions 
listed  ir  the  requirement.  Jt  calls  for  introduction  of  suet  cc r st ruct s 
as  hCAD,  ..  r<  T T F (with  or  without  format)  OPrh,  CLCSF , CM  OVFKFLC'*  etc.  tr 
accomplisf  this. 

lh«  existiro  i rrn  l t-fnt  at  i ons  havp  or  fined  ttpir  own 
non-sf  arioardi  red  I/O  features  to  rer+orm  son*3  of  t^er.  e functions. 
Imp  l empr-t  at  i or.  of  well-defined  s t a r da  r d i zed  features  ray  require 

significant  modifications  to  pxistino  ro’"'ilpr?. 


P11.  1 he  larr-nsre  .ill  rrnvidc  operations  cn  data  tvres 
defiref,  as  power  snts  of  e^urne  r a t i on  types  (see  If).  these 
operations  will  include  union,  int f rsect ion,  difference, 

CO".;  le"-ent,  an.-'  ar  plcrrn*  n red  i c ate . ....* 

Union  . P 

IntTSPCtirn  . . . ,v 

Difference  ....i 

C o - p l r r est  r 

venrership  predicate  .........................................  ...F 

(set  inclusion)  F 

The  lanouace  nrovides  the  o;  prations  of  Ck,  AND,  A-H,  VOT  rod  V’)^ 
fr  t p firfcrrred  on  hit  rtriros  ir.cludinn  thp  huilt-in  n.  ta  tyues. 
However  tk"  l annuaoe  dres  nrt  provide  for  status  variables  arc  aence 
ft(*SP  rper^tions  c?nri"t  to  anrlied  to  enumcruteri  tyies  or  their  riwer 
set.  Ufince  tne  lanouane  cnly  meets  this  requirement  partially. 
(Section  ' .1) 


Tot  lannuar*  will  hive  tr  provide  a mechanise  to  define  st  itus 
variables  an-*  f'r  (nurprotr'*  ty^es.  The  dpfiriticr  ot  thP'-*  ocerations 
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j-ill  to  re  »>^e,'r)p^  to  anr  l y to  the  roxAr  set  of  those  enjrerote-1 

tyros  . 

Tt,f>  existio-’  ir"  letrentat  ions  v-ill  have  t * tincercr  a moderr.t  <*  an'ount 
of  cton'e  in  tte  , reos  of  da ta  definition,  pxf  ressior  procession,  IF  and 
rop-/MiLF  statement  process  ina,  etc.  to  r>ccosnod»te  the  full  irrract  of 
toe  lerrua-je  *nd  i 4 i c e t i or. . 


JOVIAL  J'i  1 Z 

It'rtjirf'fnt  f 1 

Cl.  ‘•ide  effects  which  ace  dependent  on  the  evaluation  c rHec 
stop'’  tie  arguments  nf  an  expr®s«ien  will  te  evslustec 
left -t  o-r i nht  . . . . . r 

Si  ’e  effects  rest  occur  in  l r 1 1 -t  o-r  i t order  T 

( F T>r  rdcied  3ssi  nrents)  F 

.1  : provides  a drtail.ec  set  of  rules  for  evaluating  e »r.  r r s s i 'jos  . 

These  cules  eocomr.iss  the  order  of  evaluation  for  different  data  types 
anrl  of  »MtPrs  and  also  list  riles  (or  evaluation  of  sj;  'rrists, 
fjnctiors,  furiCtioral  modifiers,  u-irenth uses  etc.  In  cases  "I  (urritors 
havinu  eoual  i reccoence,  the  specifications  state  ♦hpt  the  crier  of 
"vrluation  aill  l?  from  le 4 1 -t  c-r  i iht . (cection  7) 

*c  conflict  k i f "tl  pr  r equi  r°m.f  rt  *• . 


C ? . .nir.h  tarts  of  an  expression  constitute  the  e.  p e r c rul  s to 
eacti  operation  within  that  expression  should  he  obvious  tn 
the  reader.  There  will  te  feu  levels  o*  operator  hierarchy 
and  they  v»i  l l be  vide  I y recn- ni  2er|  . . ...T 

( ev  rrecedence  levels  . ....  T 

No  Lser-definro  precedence  levels  T 

Operand  s of  t>n  operation  are  "tivicus  T 

Th<  lanauaoe  establishes  the  Merarchv  for  evaluation  r oirrssi  >ns 
for  data  types  to  ce  : <1)  double  float  (?)  sinole  float  arcs  ( t ) irtsier. 
The  order  of  evaluation  for  operators  is  also  defined  art  is  as  fellows: 
(1)  exponent  iat  icn  (hiihestd,  (?)  nn?l  t it  l i c f.t  i on  or,'  division,  ord  (3) 
unary  arc1  binary  + and  - (Invest).  .hen  two  operators  wit*  ejjjal 
precedence  level  r.re  encountered,  they  are  evaluated  from  left  tc  ri^ht. 
However,  the  crier  nf  evaluation  of  constituent  parts  of  the  expression 
is  implementation  dependent.  uenre,  the  larauaie  meets  t n i s 
reaui resent s . (Section  7) 

»u  conflict  »itr  otter  rec.u  i r »eer  ts  . 


C3.  r xpr  »*ss  i onr.  of  a niven  type  *ill  ^ .vertii  tted  anywhere 
in  source  urograms  .fere  hrth  constants  and  references  to 
varieties  c f that  type  are  allowed.  ....? 
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Jir  allows  fxprr?:s  icn.  tc  he  used  wherever  constants  and  variables 
of  a t v t:  e a re  alleged. 

•v'c.  conflict  ,. itr  other  features. 


C A.  Constant  rypressiers  will  he  allowed  in  Programs 
sny^erf  constants  ore  allowed,  ?nd  constant  expressiers  will 
re  evaluated  before  run  ti”>p.  ....F 


Tr  ttt*  d?t(i  -ec  lamtion  r^rticr.  of  the  l;-r-i>ac!c,  sut  st  itut  ior  of  -» 
constant  expression  in  place  of  a constant  value  is  not  allowed  in  J30. 
for  instance,  in  the  array  declaration  the  dimensions  ot  the  irrsy  must 
dp  integer  constants  and  not  intraer  constant  expressions.  The  same  is 
true  for  constants  in  I T r h'  de c l ? r at  ions , T*Bll  de  c tar  at  i ons  , etr. 
(Section  A. 3,  A. A,  A.S). 

The  I finaua  h definition  «hnuld  te  modified  to  allo»  constant 
evpressinrs  wherever  constants  are  permitted  in  the  uata  declarations  or 
other  features  of  the  lan.jnane. 


Ttis  modification  tr  the  lerouaoe  will  require  minimal  chanues  to 
existirc  co^ciler*  it.  the  areas  of  lexical  and  syntax  analysis.  Storage 
allocation  for  vrious  types  of  data  at  comnile  time  will  have  to  wait 
jp;ler  after  a call  to  exiression  ( rocesscr  which  will  resolve  r.  I l 
constant  expressions  into  constants. 


C5.  There  will  hr  a corsistert  set  nt  rules  applicable  to 
all  parameters,  /.nether  they  he  for  rrocedures,  for  types, 
for  exception  handling,  tor  parallel  processes,  for 
dec  l ar  at  ior  s , nr  ter  built-in  nrrtors.  Ttere  will  te  no 
special  operations  (e.n.,  array  sut  s t ru  c tur  irtn  > applicable 
only  to  parameters.  Uniformity  ard  consistency  contribute  to 
ease  of  lee  mi  m.  . . . . p 

Fsrcneter  rules  consistent  in  nil  contexts  f 

No  sjecial  operations  afnlicalle  rrlv  to  p >r amet  or s ......... ....1 


j>r  allots  parameters  for  irocedures,  tuilt-in  operators  and  for. 
declarrtions  tut  (I'-t s not  remit  tvpe  parameters,  exception  handlinq 
pirameters  and  parallel  precession  parameters.  The  lannuaee  hewever, 
does  rot  permit  special  f't'Pf ^tiors  ap"licrble  only  to  parameters. 


t. 
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I rm.uftue  cs^chi  t it  ips  4 or  tvpe  lec  l.  ratior  nirer  tier  ban'll  inn  nno 
parallel  iTocp^sin'.  will  have  to  he  uddo-1.  This  wool  4 re^uir? 
significant  era"  t(.  existing  iT"le»rnt)^ionn. 


c 6 . Formal  a nr.  actual  n?ra  m.®ters  will  el  way*  agree  in  tv—. 

The  nuinoer  o f dimensions  lor  ;rnv  nriranntprs  will  t® 
de  t r r"  i nat  l r at  Ciirjile  tinp  . 1 tit  s i ? r ann  subscript  nri’P 
for  array  DnratPtPrs  need  not  he  date  rrr  i nab  l c at  compile 
tire,  tut  can  le  passed  at  part  n 4 the  parameter.  . ...1  + 

Actual  and  formal  r t r one t e r s '-ill  air-f  in  type  T 

want  of  parameter  arrays  is  fixed  at  compile  time  I 

Parameter  array  s i /e  and  subscript  r’rqp  car-  te  passed  f 


j ' i requires  that  tie  type  of  actant  and  formal  parameters  be  the 
sane.  It  also  requires  the  nuntrr  p+  dinensiens  to  te  fixe!  a*-  compile 
time.  ( ex  ever,  it  also  specifies  Mot  Me  values  cf  the  dimensions 
(i.e.,  tie  sjnscri"t  ranee  n4  the  arrays)  between  actual  and  formal 
oaramrters  agree  . Thus  it  dc«*s  rot  alio*1  ftp  size  and  subscript  nngp 
tc*  be  | as  sec  =>s  a parameter  by  the  ucer. 

I4  t(e  lenjuage  ctfiriticr  relaxed  the  rule  requirin'  ■ a r eement 
betaeer  the  values  of  dimer siens  of  the  array  in  the  formal  sod  actual 
parameters  at  compile  time,  ther  these  values  can  be  •"issed  as 
parameters,  thus  mention  the  Timao  requirement. 

vo'Ji  f i cat  ion  of  this  lar''ur,’e  feature  will  require  minimi  changes 
in  tv"f  checkin n *rd  parameter  checking  mechanisms  ct  ’'he  existing 
Compilers. 


C 7 . (h»re  will  b®  only  four  classes  nf  formal  parameters. 

For  data  there  will  he  those  which  act  as  constants 
rer re  sent i r n the  actual  rsraru  t»r  value  at  thp  time  of  rail, 
jnl  tpcs®  which  renani®  the  actual  parameter  which  must  tea 
variable.  Tn  addition,  there  will  re  a formal  parameter 
class  f n r srecifyinn  tht  centre  l cction  when  except  ion 
conditions  occur  and  a rloss  for  -rom  jr?  parameters.  ....? 

Act  as  constants  ecall  by  value  plus) 

Ac4  as  variables  (call  bv  reference) 

Fxc—ficn  control  

Procedure  "arareftrs  

f*ct  as  variables,  but  call  Kv  valu°) 


l 


l : 


j 
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(Act  as  variables,  result  parameter) 


F 


j 'r  allows  call  by  value  and  call  bv  reference  tut  (Joes  net  provide 
tor  exception  control  parameters,  nor  dnes  it  provide  tor  procedures  to 
be  included  in  the  call,  as  actual  parameters. 

Tie  lannjat'B  definition  should  he  extended  to  alio*  exception 
handling  and  also  exception  control  carameters  (e.g.,  labels)  in  the 
procedure  calls.  Procedure  phpuld  also  t e alloweo  to  be  induced  in 
these  c u I Is. 

these  mooi f i c a t i ons  to  *he  I anouaqe  will  constitute  a maior  change 
to  existing  compilers.  Fxcertion  hardline  itself  will  recuire  changes 
or  extersions  to  ceverel  existing  laroua**e  corstructs. 


CP.  Specification  of  tie  type,  rar.oe,  precision,  dimension, 
scele,  and  formrt  of  parareters  .ill  be  octicnal  in  the 
procedure  declaration.  hone  of  them  *ilt  te  alterable  at  rur. 


time.  . . • . F 

Above  nrorerties  optional  .'*3~ 

Above  nrooerties  are  Fixed  at  run  time  ..F 


The  specification  of  raroe  and  format  is  not  permitted  in  J 
formal  oarameters.  If  a formal  parameter  is  a constant  its  scale  and 
precision  can  be  specified  bv  the  user  but  there  is  nc  Guarantee  that 
the  precision  will  be  maintained  by  the  translator.  Truncation  and/or 
roundinc  will  occur  oeoendine  unrn  the  uord  size  of  computer.  The 
njmoer  rf  dimensions  as  well  as  their  values  are  required  to  be  supplied 
■jy  th®  user  and  is  not  optional. 

To  meet  this  reruirement  several  chonaes  in  the  language  definition 
and  syntax  shall  h?>ve  to  be  made.  The  formal  parameter^  should  be 
allowed  to  optionally  contain  definitions  of  tyne,  range,  precision, 
scale  and  format.  None  of  these  cottons  are  presently  allowed  in  an 
exr  licit  form.  moreover,  cynarric  arrays  should  be  permitted  by  allowing 
the  dimension  spe ci f i cat i on  tc  he  option: l. 

] rr.n  l ementat  i on  of  dvnamic  arrays  will  require  many  changes  to 
existin'"  implementations.  other  ch’nnes  listed  in  t h ® previous 
paraorarh  will  significantly  affect  the  syntax  checkina  and  code 
leneration  rhases  of  the  pyistir”  compilers. 
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C9.  Thrre  wilt  te  provision  tor  variable  numbers  of 
ar ''u~p,ts , t jt  in  surh  c rr(»?  all  but  a co^rtart  pother  of 
them  rust  i f ot  tk  c f tTf  type  . !■>•? ttif  r a routine  can  f.ave  6 

variable  number  of  arouTpntr  must  t e dot errir ah le  from  its 
description  and  the  nurper  of  aruuments  for  any  call  will  ' e 
determinable  at  compile  t i " e . ....in- 

variable nurlifr  nf  arm^fnt*.  -ossihl*’  ........................... r 

• l l tut  a constant  number  of  argument'  H«vf  the  s are  type  F 

Nj"i*'fr  of  arguments  in  each  call  is  fixed  „t  compile  time  T 


J/!°  '•oes  not  rovin'*  »cr  a var  Table  number  of  ar-urerts  in 
procedure  calls  or  in  procedure  definitions.  T'pre  is  no  restriction  on 
t^e  ourter  of  arguments  which  must  P o*  the  same  tyre.  Th<  mj'  Lcr  of 
ariuments  in  each  call  "ust  he  fixea  at  compile  time. 

T meet  this  recuirement  the  lanona  ;p  will  have  to  provide  for 
moderate  chances  in  laoouaae  syntax.  I fk^ver,  sionificant  chances  will 
have  e o be  marie  ip  the  parameter  nassfnn  mechanisms  of  thp  t r ? r s l a t or s 
to  implement  this  charge. 
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01.  The  user  will  have  the  ability  to 
values  of  any  tyre  with  identifiers. 


The  CONSTANT  declaration  allows  a none 
constant  value.  (Section  4.7) 

to  conflict  with  other  lanmjaoe  features. 


associate  constant 

• • • • T 


to  he  associated  with  a 


02.  Tie  lancucqe  will  provide  a syntax  ana  a consistent 
interpretation  for  constants  of  tuilt-in  data  types.  *umeric 
constants  will  have  the  same  value  (within  the  specified 
precision)  in  Loth  uroqrar-s  and  data  'input  or  output).  ....P 

Literals  for  all  ^uilt-in  tyres  .........T 

Consistent  interpretation  in  r rcaram  and  data  ................... F 


j7^  rrovides  detailed  description  c>f  the  properties  of  each  type  of 
literal  (Section  l.’.i.l).  The  syntax  for  these  literals  is  described 
in  Section  v in  detail.  There  are,  however,  no  1/0  facilities  described 
fnr  the  lonouaoe  nor  is  there  a description  cf  the  relationship  of  inout 
data  to  literals. 

1/0  facilities  ano  data  format  description  should  he  provided  ' to 
meet  this  requi  rerent  . 

*mp  l ement  at  i on  ot  data  format  which  is  identical  to  the  forrrat  of 
data  literals  will  rrnuire  minimal  change  in  existing  implementations. 


C-  5 . The  lannuaoe  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  oart  o+  their  declaration. 
Such  variables  will  be  initialized  at  the  tire  ot  their 
anoarent  allocation  f i.e.,  at  entry  to  allocation  scone). 


There  will  he  no  default  initial  values.  . . . . P 

Initial  value  car  he  sjecitied  as  j a r t of  the  declaration  .......T 

In  i t i a l izat  ion  occ.ur  s at  allocation  senpr  entry  .................  T 

No  default  initial  values  .F 


The  lamuaqe  permits  initialization  of  items,  tables,  arrays, 
characters,  lits,  pointers  etc.  at  the  time  of  their  de f i ni  t i on . the 
actual  allocation  of  these  initial  values  occurs  at  scope  "ntrv  time. 


jov m jsl 

Set,ui  revert  < 


1'> 


The  lannuaoe,  however,  olsf  termits  i ni  t i a t i zat  i on  cl  verioules  by 
default.  For  instance,  unirsi  t i al  i zed  elements  of  the  array  or  tat  1“  are 
s“t  to  the  value  enuivalcnt  to  all  bi^arv  zeroes.  (Section  4.?) 

The  lan"uatic  should  forbid  initialization  of  veriaoles  ry  default 
♦ o T.eet  t^is  requirement.  This  would  lead  to  two  possible  a I t e rr.  at  i ves  : 
either  issue  ? warnin'.)  whenever  a variable,  table  or  arrav  is  used 
hrfnre  initialisation  c>r  renuire  that  all  variatles,  tables,  arrays 
etc.,  ->ust  !>e  exrlicitly  initialised  ty  the  user  at  the  time  of  tn**ir 
definition.  Tssi.ino  p warr-ir-’  if  a variable  i*  used  -efore  bein.q 
assignee  value  is  difficult,  if  not  impos  si  k'le  in  some  cases. 


D4.  Toe  source  lanoua^e  will  require  its  users  to  specify 
individually  the  ranne  of  all  numeric  variables  r n d the  step 


size  for  f i xeo  point  variaulos.  The  raoue  specifications 
will  be  interpreted  as  the  maximal  ranee  of  v a l u ” «■  which  , i t l 
be  assigned  to  a variable  and  the  minimal  ranoe  which  suet  he 
su"por  t e,J  Ly  the  ouiert  cn^e.  Tanre  and  st*  n ri?r 

specifications  will  not  l e interpreted  as.  riefini*vi  r.2» 
types.  ....F 

Numeric  variable  ranoe  sne r i f i ca t i cn  mandatory  F 

Fixed  point  variable  step  size  specification  rrandatorv  ...F 

Rsri.e  end  ster  size  soec  i f i c a t i one  do  not  define  a new  tyne  .....T 


f.per  i f i cat  ior  r><  ran  ;es  of  variables  is  not  mandatory  in  J'l  , nor 
is  tfere  a lanouane  notion  available  to  explicitly  specify  the  ringe. 
The  ran t, e is  implicitly  dependent  upon  the  word  size  of  the  machine. 
The  same  ornirents  are  applicable  for  fixed  point  variables.  No 
explicit  option  is  permitted  to  srrrify  the  ster  size  of  fixer  point 
variables.  Thus  the  lannuaoe  aces  rot  meet  this  requirement. 

fcxf  licit  lar:uaae  options  should  f <;  provided  to  sperifv  ranoe  of 
variables  and  arrays.  similar  oj-T’ors  for  step  size  s ■ °c  i f i cat  ion 
should  I e rrrvidfo.  Imp lemertet ion  t*  these  facilities  will  require 
minimal  chames  in  the  svntav  chprl<ino,  code  aeneration  and  storaoe 
allocation  functions  of  h^p  existing  translators. 


05.  The  ranee  of 
variable,  array, 
ty.  e,  anv  de f i md 
enurerat ion  tyi e . 


valuer  vtirh  cm  be 
rr  recnr'4  ermreneot, 
tyre,  or  a contiguous 


associated 
will  t e any 
subsequence 


with  a 
l ui 1 1 -i n 

of  anv 
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Par.,  p$  o*  an  enumeration  type  are  allowed  F 

No  arbitrary  restrictions  on  the  structure  of  data  .............. F 


JdP  ^oes  not  alio*  explicit  association  of  a range  cf  values  with 
variaoles,  arrays,  or  components  cf  a record.  It  dees  not  allot*  defined 
type  or  enumeration  cf  data  ?ne  hence  also  ooes  net  permit  their 
association  with  ian:e  of  values. 

the  l anouaoe  restricts  array*  t c he  declared  as  part  of  data  tables 
(records)  (p.  4-0  and  vice  versa.  Hence  it  tails  completely  to  meet 
this  requirement . (Sections  4.3,  4.4) 

T-  fully  meet  t*is  requirement,  the  lanouaoe  will  require  major 
modi f i Cu t ions  to  its  definition.  It  must  first  allow  user  definition  ot 
new  data  tyres,  enumeration  nf  nets  via  status  variables,  and  permit 
records  in  array  and  arrays  in  record  definitions.  Then  it  should  alio ,< 
specification  of  a renrje  ot  values  for  e;>ch  of  these  cases. 

4 

t- 1 1 existinn  implementation*-  will  b;  ve  a major  impact  as  a result 
ot  these  chants. 


D* . The  lanouaoe  will  provide  a pointer  mechanise  which  can 
oe  used  to  luild  data  with  shared  and/or  recursive 
substructure.  The  pointer  rronertv  will  only  affect  the  use 
ot  variables  (includinc  array  and  record  components)  of  some 
data  types.  Pointer  variables  will  he  as  safe  in  their  use 


as  are  ary  other  variables.  ....P 

Recursive  and  network  structures  provided  .......................  T 

Handles  variable-value  and  structure-romrenent  connections  ......T 

Pointer  r reperty  is  an  attribute  of  a tyred  variable  ............ f 

Pointer  property  not  fc-r  constants,  affects  only  assionment  .....T 

Printer  rrorerty  mandatory  for  dvnamic  allocation  ............... f 

Allocation  scope  never  wider  than  access  score  .................. F 

(Either  the  value  or  the  printer  ic  modifiable)  I 

(Pointer  mechanism  handles  procedures  and  parameters)  ........... r 

(Remap  and  replace  assignment  have  different  syntaxes)  .* 

(built-in  dynamic  variable  creation)  ............................  F 

(Variable  eouivalence  classes  are  Heclnr»tle)  ................... F 


The  lanouaje  provider  for  printer  rations  which  can  no  us*  i t •> 
share  data  values  as  well  as  + o build  recursive  data  structures.  The 
pointer  mecharism  can  nr  used  tr  connect  a pointer  variable  with  a value 
= s well  =*s  t-o  a structure  or  to  its  component.  however  the  language 
-hies  not  ®nsure  safety  wMI*  usino  this  mechanism.  it  is  up  to  the  user 
tr  ensure  that  r,  > values  »re  arr,e*sei.*  n^ich  are  leyend  the  srore  ot  the 
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f-  e,ou  i r i ^et.t  DA 


r>r;irtcr  veriahle.  »o  dy>-,i">ic 
t^e  larnuane  only  partially 
/ .4 ! 


a l locatin'!  of  variables 
"left1?  the  '“prui r»>rent . 


is  allowed.  Hf  nc  *’ 
(Section  8.4,  ? . t , 


lr  riT'et  tHs  recju  i rer  e nt  the  pointer  -necharism  will  have  to  be 
extended  included  as  oart  of  the  type  definition.  T o provide  oil 

the  curabilities  listen  ip  tt  e re  noi  r ement  will  be  a najor  cnar.cjff  in 
ex  i s t i i mj  It-nc^t  »t  i "'5  . 
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r 1 . The  user 

.f  the  lanouare  will 

te  ah  l e to  cefire 

new  dat-a 

tynes  and  ooer 

Ttions  t.i»hin  rroirsn s. 

• • • • 

t 

J ' 1 ^ops  not 

permit  definition 

ot  user-defined 

data  tvp°s 

or 

noer at  ions . 

The  InmuP'H’ 

must  he  chanced  to 

allow  a meet  ani  cn 

to  defire 

nr  v 

o ,1 

ta  tyfes  ano 

derations.  Once 

rfetinen,  these 

data  tyres 

and 

era t ions  should 

t-e  niven  the  same 

treatment  as  the 

t u i 1 1 - i r 

fata 

types  . This 
specification 
at  locate  and 
rie  allowed  to 


includes  tne  lannuaoe's  ability  to  permit  initialization, 
of  ectiors  to  he  taken  at  termination,  capability  to 
deallocate  these  defines  data  types.  Defined  ty'cs  should 
be  -*ormed  'rmr  built-in  types  vie  enumeration,  cartesian 


products,  discriminated  union  and  pnwprsct  e*  enumeration  tyo«, 


implementation  ct  this  definitional  facility  und  the  associated 
type  checkinc;  required  will  te  a major  uodertakinq  affectinq  syntax 
analysis,  dictionary  entries,  code  ocneratior,  di annost i c s J etc. 


12.  fte  "use"  of  definto  tyjes  pill  t « i ndi  st  i r.qui  shah  le 
from  huilt-in  types. 


siren  there  are  no  defined  tynes,  ttis  reouiremert  is  not  met. 

As  explained  in  FI,  the  lann-jaqe  should  permit  definition  of  new 
data  tyres  and  make  them  indistinguishable  from.  built-in  tyres. 


r3.  Fact  prcorarr  component  will  he  defined  in  the  base 
lanuuaoe,  in  a library,  nr  in  the  nrooram.  There  will  be  no 
default  dec  la  r -it  ions . ...,T 


j 7 o requires  that  each  rrourat  component  he  defined  ann  cieclared  in 
rhp  rrooram.  Itftrs,  arrays,  tables,  -roceduf es , etc.,  must  be  cectared 
at  S Y $ T r * , C 0*P00L  , ^LO^L  or  L AL  levels.  The  compiler  will  not 
substitute  definitions  for  undeclared  nares  by  default.  Instead  it-  will 
siive  a comrile-ti'e  error. 


<o  ronflict  with  other  land'anes  features. 


j.'HIal  j'' 
t enui  re  -cr  t fc  /. 


’>  r> 


T4.  The  user  -ill  he  at  l » , within  the  source  lerots  jp,  to 
0Kt°r1  exist!*'  otrr^tors  tr  » e»  ritt.'j  tyre?.  ....F 

sirc«-  t^e  l c nuai’f  does  rot  rpriit  defined  typer,  it  does  rot  r^et 
*.l  is  r“i  uirrrent  . 

*e  r the  score  of  the  needed  rrodi  *i  cat  ic  n« , see  ri. 


F j . Type  definitions  ir  th ? enurce  lanruace  w i l l permit 
definition  of  I rth  the  class  ot  data  oMects  coTprisinr  ‘ne 


tyi  <.  the  set  of  f'l  f ration*  r<p*  licule  to  tf^t  class.  * 

''etieej  ty;  e ,.  •*  l l not  aut  cr*t  l c?  1 1 y inherit  the  operations  of 
the  cata  with  ahich  it  is  represented.  ....f 

Conr t ructi on  ,r 

Selection  .................F 

freniC'tes  .......* 

Tyre  conversin''*;  .............................................  ...F 

L'CPrdt  ior  s ano  data  can  te  cJetineri  tocether  F 


T h c J*’  l enroaoe  tines  rot  rrovi^e  the  facility  for  user  detinel 
data  tjf.es  and  oeclarinn  the  lift  of  operations  applicable  f~  fh.it  nfJ 
tvnes  . 

This  is  an  “ytensirn  of  the  facilities  discussed  in  M.  Frcvision 
should  k>e  made  to  define  t f e applicable  operations  for  ie fined  iita 
types.  These  car  be  built-in  operations  or  user-defined  operations. 


ft,.  Tre  data  objects  comor i r inr  a oetireo  type  will  t e 
definable  hy  enumeration  pt  treir  literal  names,  os  Cartesian 


products  of  rxistim  tynes  (i.e.,  as  array  and  record 
claries),  by  d i s c r i » ir.at cn  u"ior  'i.e.,  as  the  union  of 
disicirt  tyres)  arn  as  the  , raer  set  nf  an  enurne  r .1 1 i c r fya, 

The  si*  ^“finitirnr  will  be  processed  ertirely  at  conpil" 
t i ->•* . ....F 

E nur. « r at  ion  1 

ferttcian  t roquet?  freccrds)  F 

h i s c r i ” i na t eH  union  i 

f-nwersit  of  an  “Puffier  it  im.  tyre  ...r 
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J Vr  ^rcs  not  sut port  defined  tyr  c*  *»t  all. 

frr  th"  s c op  f of  the  reeded  moni  f i cat  i on«; , see  1 1 . 


F7.  T yop  de4initionr  ry  tree  union  <i.e.,  union  of 
nc  n--’1 ~i  c.  i ii  r.t  tyre?)  and  suf-settino  ar<  not  oesired.  ,...F 

The  ft  v’FKL  *Y  feature  r<  provi'er  tree  union,  amor  t nt^er  thins. 

To  remove  The  TVFRL'Y  capaiility  would  oreatly  simplify  existing 
compilers,  but  would  have  a profound  effect  on  existino  prourams  written 
in  J 3n  . 


t y . -hen  iefinino  a type,  the  user  will  he  able  to  sperifv 
the  initialization  and  finalization  procedures  for  the  tyre 
and  the  actions  to  he  taker  ft  the  time  cl  allocation  and 


deallocation  of  v^rnoles  t4  at  t yp  ■*  - ....f 

Initialization  ...........r 

Finalization  ....F 

Allocation  actions  ............................................ . . r 

heal  location  actions  ....h 


J‘V  roes  net  su-Tort  defines  tyres  »t  all. 

for  the  scare  o t the  neeoen  modifications,  see  El. 
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ri.  inc  l^rrMj,;f,p  vill  allow  thp  i.srr  If  ,4i  st  inqui  sh  between 
sc<m  *•  al  U c-’t  in”  ar.tj  sccpp  rr cirs.  . ...i 


Tne  j <•»  terr’uane  c lear  Iv  dr  Mnei  ard  rist  inqui  shes  r'Pttfppn 
tvoes  r.  f . I location  scopes:  rYrT!'v,  C(vf'*OL,  MPPlL,  and  LOC’-l.  It  'Is™ 
s,eci4ies  the  a ccns?  scope  for  variables  declared  within  pac1"  of  tnesv 
ircludir.’  the  rifles  4p*"  arc®*'  i ric  the  arpro^riatP  variaKl°  <h°r 
t *<•■■  variables  Mt«  the  «s.*-e  rare  are  til  cate*  in  that  scope.  (faction 
5 .o> 

\;  c conflict  • i t ^ ether  lanai  .iran  *e-<  tores. 


F?.  The  .utility  to  liTit  the  secars  to  separately  defined 
structures  will  be  available  both  where  the  structure  is 
rfefi®en  a^d  where  it  is  usef.  It  will  he  possible  m 
asscriat®  rit,  local  raTrs  with  separately  defired  rrno mr 
cot;  on»ntl  . 


Allowable  oieritions  can  he  liTiter'  r 

Access  can  he  l i mi  ten  where  used  *’ 

Exttrnr.l  oec  I a rat  inns  ncec  rot  nil  >ave  the  same  sccrc  ..........F 

ha»int;  conflicts  car  hr  fi/cice'*  (rpnarim)  ...................... F 


J*l  does  not  allow  the  capability  to  li*it  access  to  structures 
^liere  they  are  defined.  For  r»?ni  U,  structures  aeti^eo  a*  GLOlAL  ire 
accessible  fron  all  cnn'Cncntn  o4  a -rceram.  However,  the  access  to 
these  structures  car  be  lieiteo  or  where  used  r.  v redefinino  tht- 


* t rjc  ture 
inaccessi 

at 

pie. 

1 oca  1 level. 

In 

such  cer«s.  the 

rlohal  value 

vi  l l 

b e 

J : f 

rexes  f r r 

doe  s 

tee 

not  permit  a 
sane  entity. 

reran  i r,  curability 

to  r l lew  two 

or 

7>t>r  ** 

frpjitional  lanouare  capabilities  will  h ’Vf  tr  be  introduced  t ; 
«occifv  the  scone  cf  a variable  at  fh®  tire  of  its  definition  and  also 
at  the  ti^e  of  its  use.  Ttis  facility  mist  also  he  extended  to  ripfinei. 
nota  tyres. 

» rerrf'iro  Capability  tr  establish  equivalence  bct.®^  several 
fifferert  n;tn®s  should  a 1st  b®  aroed. 


1 r t r oduc  t i on  rt  these  chanoe*-  will  effect  nil  existinq  coffri  l®rs 


JOVIM  J3rj 
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f l.  The  score  of  identifier*  will  be  wholly  Determined  it 
cr  '»'•  i l *-  t i me.  . . . . T 


Jit  estat lisres  the  scope  cf  each  identifier  at  the  time  of  its 
definition.  See  M < *rd  F}. 

No  conflict  «ith  other  lapriiait  features. 


FA.  * variety  of  epr  l i c a t i or-pr  i er  t ed  data  and  operations 
will  be  available  in  libraries  ar.d  easily  accessible  in  the 
l en*’ua  e.  . . . . I 


J*F  provides  for  come  no  Is  ?pd  library  capabilities.  It  defines 
certain  built-in  functions  (called  functional  rcdificrs)  in  the  lanqjiue 
and  remits  the  user  to  ado  as.  many  application  oriented  functions  a^d 
procedures  as  necessary.  User  can  also  "'efine  data  in  various  cornools. 
“erce  tie  lannuane  meets  this  requirement. 

conflict  with  other  lannuaae  features. 


F5.  Program  components  net  defined  within  the  current 
C roe  ram  and  not  in  the  base  larquaoe  will  he  maintained  in 
conriif.  tine  accessible  libraries.  Ihe  libraries  will  be 
caoable  of  hrlding  anythinu  definable  in  the  language  and 
will  not  exclude  routines  whose  holies  are  written  in  other 
source  lamuanes.  ....p* 

Prcrram  component  libraries  accessible  at  corrnile  time  ..........T 

Lihrarie*  can  contain  foreicn  lanruaor  routines  P 

Interface  requirements  checkable  at  ccmrilo  tine  T 


J7f  remits  library  procedures  to  be  accessible  to  thr  user  at 
compile  tine,  utilirinr  either  IMLI^f  or  COPY  options.  It  also  remits 
interfaces  with  assertly  Irnouanc  routines,  but  does  not  specify  if 
interfaces  with  compiled  routines  originally  written  in  ether  hioh  order 
languaues  is  permissible  or  net.  Hence  it  only  partially  meets  this 
rorti on  o * the  requirement. 

J 'r  requires  all  interfaces  within  the  library  and  nther  procedures 
to  he  checked  at  compile  time. 
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•fully  meet  this  requirement  the  lancueqe  definition  vill  have  tr 
”e  exterufed  to  specify  hrv  J if  will  interact  with  routine?  written  ir, 
vitK«»r  hi»h  oraer  lanouanrs.  The  simnl*st  way  to  ireet  this  '■esui  recent 
.ill  hr  to  rile*  interfaces  with  compiled  versions  of  thes>‘  languages, 
requirin'-  J,r  compilers  to  utilize  header  information  ir>  comniled 
programs  to  te  used  for  establishing  the  interface. 


Ft.  Litraries  and  Ccmpocls  will  he  i ndi  st  ingui  shah  le  . They 

will  he  capable  of  folding  anything  definable  in  the 
language,  and  it  will  hf  possible  to  associate  thee  with  ?n y 
level  of  programming  activity  from  systems  through  project* 
to  i r n ividua  I rrocrat*.  There  -.-ill  he  many  specialized 
cot j cols  nr  libraries  any  user  specified  subset  of  which  is 
immediately  accessible  from  ?.  'jiver  program.  ...,p+ 

libraries  and  compocls  »i  1 1 he.  i ndi  s t ingui  sh  it  le  .° 

Immeri^tely  accessible  sublibraries  at  any  level  ........T 


Jit  permits  both  corpools  and  libraries.  Cm, pools  can  b»-  used  frr 
boldine,  data  definitions,  while  libraries  can  he  used  tor  storing 
procedures  and  functions.  » proiect  can  create  its  ov-n  s**t  nt  crmpools 
and  litraries.  mowever,  the  two  concepts  of  com, pools  ind  libraries  are 
■•ist  inuuishable  from  each  other.  Tven  their  invoratiens  in  r.roqrams  are 
fiffeeent.  (t  declaration  from  a crinpcol  is  accessed  via  COTPOOL 
construct  (Section  3.1.2)  while  a library  routine  is  iccer.scH  v-jd  a call 
staterert  (Section  5.3.1)  consisting  ct  procedure  name  followed  hv 
actual  parameters  in  parentheses.) 

To  make  the  comp no l and  litrary  indistinguishable  to  the  user  a 
simple  change  car  be  made  in  tKe  larouage  syntax  tr  make  the  two  types 
of  accesses  identical  tn  each  other,  T mr*  | ementation  o4  these  c banner 
without  altering  the  actual  implementation  of  comfcolc  and  libraries  cin  j 

np  accomplished  with  minimal  effort.  However,  to  combine  the  comoonl 
and  library  io  the  compilers  an-*  also  make  them,  ind  i s t i noui  sh  afc  l e to  tb" 
user  *ay  require  changes  in  compiler  design  of  moderate  proportions. 


F7.  Top  source  lanouanc  -ill  contain  standard  machine 
interendent  interfaces  to  machine  oerendent  capabilities, 
including  »eri*-herrl  eouirment  and  special  hardware.  ....T 


The  language  provides  interfaces  with  machine  dependent 

capabilities  via  pr eprocessed  comtools,  assembly  language  code,  mg 


t 


•i 

I 


A 
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rertfir-  functional  modifiers  ft.:.,  SHI  f T R , SHIFTL  etc.).  All  r.achine 
lerer  1*  rt  caraoilities  including  I /C  m'  interfaces  with  ceripheral  ,m.j 
nt-ecirl  hardware  -list  be  crned  i-  assembly  lanouaqe  rroceriurts.  These 
r r u 1 1 o e s cm  th»n  bp  interfaced  ,itt  j?h  ->ron  r amc  via  i call  to  t^se 
n r rc edu re s . Hence  the  Ur.iuatie  epets  this  r eenj  i rer.ent  . 

‘c>  conflict  „itb  ether  l a nnu  a r'  e features  . 


jJv'iai  ji  u i y 
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r^.  Ji>e  Inniuff  e will  provide  structured  control  mechanisms 


tor  s m uent  i <- 1 , condi  t i or ■■  l , iterative,  and  rerursiv" 

ccrtmi.  ]t  i ((  al«o  rr^vide  control  structures  (or 

(ps«udc>  p»  r»l  lei  p. r oce st  i no  , e<c»ct  kh  ban  dl  ini,  , nd 

asynchronous  interrupt  hanolis".  . . . . i’ 

Seojertial  execution  . . f 

Conditional  execution  . . ...f 

iteration  I 

l«e curs  ion  r 

(Pseudo)  parallel  procession  r 

Exception  rand  l i r o ...c 

Asyrrlrcnf us  interrupt  handliro  .................................  r 

rortrol  structures  f®om  o snail  set  of  si^nle  primitives  1 


tre  lanouaoe  p.rovides  tor  sequential  execution  of  s t at  e^t  nt  s , ids 
1 f - T H r v-F  L ? r and  SWITCH  condition*!  control  steterrents  and  fno  iteration 
louo.  It  -toes  not  provide  for  recursion,  parallel  oroerssir?,  exception 
handling  nr  interrupt  handlino.  If  is  doubtful  it  tie  existing  control 
primitives.  can  be  used  to  builf  new  control  structures.  (op.  ?-5, 
Section  5) 

vaior  changes  will  Have  to  be  made  in  the  existing  control 
structures  of  the  lannuaot  to  meet  this  requi  rerent  . Cap«u*  i l i t i e s for 
recursion,  parallel  rrcceesinu,  interrupt  handlim  and  exceotion 
handlin'  ..ill  fn-.ve  to  be  a coed.  Furthf  rrrore,  construction  ot  complex 
control  structures  using  existin'.;  control  primitives  reguires  that  a new 
set  of  control  primitives  he  developed  which  allows  such  complex  control 
structures  to  b®  huilt  via  mechani  s"s  such  as  concatenation,  procedure 
calls,  etc.  *11  existino  i fr  p lexentat  ions  will  hav®  n Taior  impact  on 
nhe®  rs  a result  of  tnese  cnannes  in  the  Ipnnuanr. 


<>2  . T*  e source  lanouane  will  Tovide  a "so  TO”  op®ratior 
annlicrhle  to  pronram  labels  within  its  most  local  scope  of 
definition. 


. . Pt 


t p * lanouaoe  provides  *rr  r,p to  and  specifies  that  the  transfers  of 
control  be  limited  to  labels  declared  in  the  same  rroceoures  or 
functions  in  ..hicn  the  f.OTO  occurs,  however  it  does  permit  tranches 
from  ' 'ain  nronr  - it.  t"  the  labels  v‘i*-hin  its  orocedurrs  or  functions  via 
orocecur®  or  function  invocations  and  label  parameters.  Thus  it  onlv 
partially  meets  t^is  recuirement.  (Section  5.4.1) 

Tre  lunnuane  should  exclude  transfers  of  control  via  l.ao®ls  from  a 
main  ''rooram  to  references  inti,  its  nroedurf • and  functions. 
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! r l e r t nt  ■>  t i c.  n 
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this  chance  „ i 1 1 


hr.ve  v minimal 


impact  on 


’ 7 . Thr  conditional  control  « t rur  tur  e s -ill  bp  tully 
ocMitioned  o;a  .-ill  permit  so  lection  amcno  alternative 
to"i  it.it  inns  ►'.•sec4  on  trc  value  of  a boolean  exrression,  on 
t h i stibtyor  t f a v-»ljp  ircT  a it  i s c r imi  nstt14  union,  nr  nr.  a 
crnotp'4  crnim  amoro  labeled  alternatives.  ....ut 

►.-•so''  on  h i s I •*  r-  n r x ( r e « s i o n ................. ....................T 

baser  cn  type  1 ro1-.  d i sc  r i - i na  t e d unior  ..........................  r 

r,i:s',r'  on  r r-m^  u * e h ctoire  a ~ r r '•  labeled  alternatives  .............  I 

Ml  alternative  must  t « sccnu'-teJ  for  ‘ 

s i r p l r»  ^ p t b a r.  i s t.  s i.  ill  I c s up  r I . i e d tor  comron  cases  .............T 


Tre  lan-niave  '-rovi'Jes  for  I r - i H F s -C  L Sc  and  SWITCH  conditional 
control  structures.  In  the  Tl  statement,  the  unclean  excression  (bit 
formula)  »as  tn  ►f  evaluated  before  t^e  next  course  of  action  is 
dete  rrrire."  <Ser.tir.n  S.b).  however,  it  does  not  permit  selection  of  an 
rilternr  t ive  based  ur<~r  the  value  Irs*  'i  discriminated  union.  The  SWITCH 
strtr-er.t  remits  a choic®  from  n»or>c  t^e  labeled  variables.  The 
ot^er-isc  clause  is  not  r rcvirea  for  in  the  J SWITCH  statement,  hence 
all  alternatives  are  not  provider  ►or  in  this  case. 

To  fully  meet  this  requirement  the  lanquaoe  has  tc  he  rocified  to 
incluct  tbr  OTl'fcRW  ISF  clause  in  the  SWITCH  statement.  furthermore  it 
shoulc  r l l ow  splectior  nf  an  alternative  based  unor  the  subtype  of  a 
valje  Iron  » discr  ie  inated  ur  irr  in  the  SWITCH  statement. 

■'irioal  ch nr.es  to  existin']  rn"-rilers  .’ill  he  required  to 
accommodate  *Hese  lar  iua?p  modi f i cations  . 


■'  '• . The  iterative1  control  structure  w>  l l cer-'it  the 
termination  condition  tc  an;  ear  anywhere  in  th*'  Inon,  will 
renuire  control  variables  tr  bp  local  to  the  iterative 
cortrol,  will  allow  entry  only  at  the  teed  of  the  loon,  ano 
-ill  not  iru'S*  excessive  overtenc  in  cUritv  cr  rur  the 
execution  costs  for  ro«  o n « > , e c i r*  l case  trrmination 

ci!nHit  ior.S  (e.  i.,  fixed  rjnfu  r M iterations  cr  elements  of 
an  array  ex h>  = listen).  . ...b* 

Termination  c-r1  nrfiir  a r v v b «» r *■  in  tHp  low.-.  ......................  T 

dultifle  t it*  ir  at  i r.  ••  credit  iti'S  are  possible  ....................  I 


Control  v^lue  is  efficiently  available  alter  termination 


Tl « * Oft  loor  in  very  nearly  meets  this  r roui repent . It  allows 
termination  of  a loon  via  a COTO  or  IT  statement  anywhere  ir  the  loop. 
Fntry  ts  the  loot  is  permitted  only  at  toe  top.  The  control  variable  is 
local  to  the  looo  ana  can  he  assigned  to  or  used  in  formulas  within  the 
loop.  but  its  value  upon  exit  from  the  loop  is  dependent  in  the 
imnlpmcntation  and  is  net  lanouane  defined.  (Section  5.6) 

The  language  should  require  th3t  the  value  of  the  control  variable 
should  not  only  he  available  upon  termination  of  the  loon  after  a normal 
or  sbrnm-l  exit,  hut  should  also  he  well  defined.  It  must  not  he  left 
to  be  implementation  dependent. 

Minimal  channes  tc  seme  of  th»  existing  imp  lement  a*  i c-ns  will  be 
required  to  include  this  larouane  modification. 


65.  recursive  as  well  as  nonrecursive  routines  will  he 
available  in  the  source  language.  It  will  net  he  possible  to 


defire  procedures  within  the  body  of  a recursive 
orocedure.  ....F 

\o  recursive  procedures  within  recursive  procedures  ............ .F 

(Maximum  denth  of  recursion  can  he  specified)  ....F 

(Recursiveness  must  be  specified)  ................F 


Tnc  lannuaie  does  not  remit  recursive  options  either  during 
procedure  definition  «r  durin~  data  definition. 

The  lannuare  w-urt  provide  the  options  to  define  recursive 

procedures.  If  the  notion  is  not  snecified  the  procedure  should  be 

taken  to  he  non-recurs i ve . TFus  no  penalty  during  code  generation  will 
be  paid  for  this  option.  Tie  maximum  death  of  allowable  recursion 

should  also  be  snecified  in  the  language  to  keep  the  generated  code  and 

stacks  to  manageable  si ?e . 

Moderate  cl  shops  to  existing  compilers  will  he 
implement  this  feature  in  the  language. 


■ 

L 


necessary  to 
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06 . The  source  l.onnuane  ►ill  provide  a parallel  processinq 
c a k’<it>  l i t y . This  capability  should  include  the  ability  to 
create  and  terminate  (possible  r-seudo)  parallel  processes  and 
for  these  r recesses  *r  oein  exclusive  use  of  resources  ciurine 


specified  portions  of  their  execution.  ....F 

Able  to  create  and  terminate  parallel  processes  F 

Process  can  cain  exclusive  use  of  resources  .....................  F 

No  parallel  routines  within  recursive  routines  ..........F 

no  routines  within  parallel  routines  ..F 

maximum  number  of  s i mu  1 1 ane  ous  instances  are  declarable  .........F 

(Access  rules  are  enforced)  ..F 


No  thskino  or  parallel  rrocessim  features  are  present  in  J31‘. 

Implementation  cf  parallel  processino  features  will  require 
definition  of  lan:-uaoe  features  for  schedulino  parallel  tasks,  providinq 
+ or  intercommunication  between  parallel  t?-sks,  interrupt  handlino, 
waitino  and/or  sync  hron  i ?at  i on,  nroor-m  swapping,  priority  handling 
etc.  TMs  is  a major  undertaking  *>hich  will  require  significant 
additions  to  existing  con-oilers. 


67.  The  exception  hardline  control  structure  will  permit  the 
user  to  cause  transfer  r-t  control  and  data  for  any  error  or 


exception  situation  which  mioht  occur  in  a rrooram.  . . . . F 

Pronra*  can  oet  contrnl  fer  any  excertior  ....................... F 

Far? meters  can  be  passed  ..............F 

Can  -jet  out  of  any  level  of  a nest  of  control  F 

Can  handle  the  exception  at  any  level  of  control  ................ F 


Mo  provision  is  available  via  the  lanquaoe  features  to  provide  the 
user  with  the  facility  to  recover  from  arithmetic  overflow,  space 
overflow,  hardware  interrupts  or  any  other  exception  situations. 

I amuaqe  facilities  to  provide  for  various  exception  situations 
should  be  added.  Imp lementatino  of  these  facilities  will  involve  a 
moderate  to  larne  effort  in  the  existinn  compilers  depending  upon  the 
number  and  tvpe  o 1 excention  features  involved. 


6h.  There  will  be  source  Ihniu-’ne  features  which  permit 
delnv  on  any  control  'nth  until  some  specified  time  or 
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situation  has  occurr»d,  which  permit  specification  of  the 
relative  priorities  amo  nr  parallel  control  paths,  which  -jive 
access  to  real  time  clocks,  which  permit  asynchronous 
hardware  interrupts  to  t*  treater*  as  any  other  excretion 
situation.  ....F 

Frioritv  specification  F 

Syo cn roni z? t i cn  via  wait/enable  operations  ......................  F 

wait  for  end  of  real  time  interval  f 

wait  for  end  of  simulate'-*  tii;>e  interval  ......F 

• ait  for  hardware  interrupt  

(Can  enable  and  disable  interrupts)  F 

The  language  does  not  permit  priority  specification  b>  task  or 
prorjrai'S,  wait  option  or  any  other  real-time  features. 

Lsnnuaje  definition  will  have  to  be  extended  to  provide  tor  various 
real-time  features  specified  in  the  Tinman  requirement.  It  will  re3Jire 


moderate  effort  to  implement  these  features  on  existing  compilers. 
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Ml.  The  source  lanouane  will  be  tree  format  with  an  explicit 
statement  d«limit*r,  will  allow  the  use  of  rrnemoni  ca  l ly 
significant  identifiers,  will  he  based  on  conventional  for*s, 
will  have  a simple  uniform  and  easily  parsed  grammar,  will 
not  rovi^e  unique  notations  for  special  cases,  will  not 
oermit  abbreviation  of  identifiers  cr  ley  words,  and  will  he 
svnt«,ct  ica  l ly  unambi  puous  . 

Free  format  w i ♦ h statement  terminator  

trercric  identifiers  ! ossicle  . 

°ased  on  conventional  forms  

Simple  qrammar  

No  s ecial  case  notations  

No  a r.b  re»'i  p*  i ons  of  identifiers  or  keywords  ................. 

Unnrt  i-'ueus  nr^mmar  


P ♦ 


T 

T 

T 

t 

T 

r 


i 


J 'f  v*ry  nearly  meets  this  reoui remert  . It  allows  statements  to  he 
written  in  free  format  ir  columrs  1-7?  of  a line  or  card,  terminated  by 
a semicolon.  It  allows  identifiers  to  be  two  or  more  alrhanjmeric 
characters  in  lenotb.  The  user  can  thus  select  mnemonic  names.  The 
conniler  is  oblioated  on  I v t m ?»3«iisp  tf  e first  e i oh  t characters  of 
identifiers  to  determine  unioueness.  *anv  conventional  notations, 
includiri  the  left  to  rioht  precedence  rules,  are  observed  dy  toe 
lanoua:;e.  There  ere  no  lanouaoe  features  which  cater  only  to  special 
cases,  and  no  abbreviations  of  keywords  '■re  allowed.  Ir  most  c*ic  s to* 
lanouaut  constructs  are  clear  and  unanbioucus.  however  there  nr*  some 
exceptions.  ror  instance  the  constructs  1NTGP  ano  INTw,  r>EF  and  rrfl»ff 
are  syntactically  very  close  to  each  oth<*r  and  awbionous. 

All  lanouaoe  primitives  should  he  syntactically  distinct  frem  p-tcit 
other  to  avoid  ambiouity.  minimal  chanoes  to  the  lanquaoe  and 
implementations  will  t.e  required  to  meet  this  reouirement. 


M2.  The  user  will  not  he  able  to  modify  the  source  language 
syntax.  Specifically,  he  i 1 1 ”ot  be  ablp  to  rrndifv  oreratnr 
hierarchies,  introduce  new  precedence  rules,  define  new  key 
,-orri  iorms  or  define  new  infix  operator  precedences.  ....T 

J7.M  has  well-defined  fixed  syntax.  The  user  is  not  "llowed  to 
modify  any  primitives  or  lannueo*  constructs  f*.g.,  statements). 


No  conflict  with  other  lanni  ->"e  femtures 


f 

I 
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Hi . T he  syntax  of  source  lanouaoe  nroorams  will  be 

ccrrpsiitle  frerr  l character  set  *uit»tle  ter  rublication 
pur  <'S°s,  ^ ut  rp  feature  ct  t^e  larouepe  will  he  inaccessible 
usim  the  1 4 character  ASCII  suhspt.  ....F 


J7r  character  s»t  consists  ot  ?<,  unper  case  alphabets,  the  decimal 
dioits,  and  other  It  special  characters.  Furthermore  it  allows  an 
undefined  number  of  imr lementaticn  defined  leoal  characters.  Jf  the 
irol “mentation  permits  characters  other  than  those  available  in  ASCII, 
then  the  Unuanr  permit*  such  characters  in  its  definition.  Hence  it 
does  r(t  meet  this  reoui  rement . 

Ji:  refinition  should  forhir  implementation  cefireo  characters,  not 
available  in  ASCII  character  set,  to  he  included  in  the  Itnquaoe 
lefinition. 

minimal  changes  will  be  reauired  in  some  implementations  to  provide 
for  this  lanuuaue  moo i f i cat  ion. 


IK.  The  lencjaije  oefinitior  .ill  provide  the  formation  rules 
*nr  identifiers  .and  literals.  These  will  irclude  literals 
for  numbers  ant  character  strips  and  a break  character  for 


us»*  internal  tu  identifiers  and  literals.  ....P 

Break  character  exists  f 

(Literals  are  sel  f -identi  t y inn  is  to  fyoe)  ...........T 

(Bit-strinu  literals  for  any  tvne)  I7 

The  la nnueoe  provides  for  formation  rules  for  literals  and 


identifiers  (Sections  ?.?./>,  ?.«?).  however,  the  lanquaoe  does  not 

define  a Create  character  tor  use  within  the  identifiers. 

The  lanouaoe  should  recognize  a break  character  (e.o.,  underscore 
or  space)  for  use  within  identifiers  to  provide  readability  in  these 
construct  s . 

minimal  changes  in  syntax  cneckina  procedures  will  he  required  to 
accommodate  this  chanqe  in  the  lir.quaqe. 


M5.  Th»re  will  he  no  continuation  of  lexical  units  arsons 
lir.es,  our  there  will  f®  o .ay  to  include  object  characters 
such  a?  end-nf-line  in  literal  strinq*. 


F 
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J 3P  rrovides  tor  a co^tinums  stream  of  input?.  After  column  72  of 
a card  or  lir.r  the  first  column  of  the  **ext  card  or  line  is  taken  to  ie 
the  next  charset****  in  cent  inuat  i on  . It  therefore  permits  cc nt i nuat i on 
of  lexical  units  icrrss  lines.  for. 

To  meet  this  requirement  tre  language  definition  will  nave  to 
forbid  the  continuation  of  lcxic?l  units  across  lines. 

vini*r.al  changes  will  he  reouired  to  implement  this  change  in 
lexical  and  syntax  analysis  phases  of  compilers. 


H6.  rey  words  will  he  reserved,  will  he  very  few  in  number, 

•ill  he  informative,  and  will  net  he  usahle  in  contexts  where 
an  identifier  car  dp  used.  ....T 

The  language  allows  only  53  reserved  words  which  cannot  te  used  as 
identifiers. 


X'o  conflict  wit**  rther  reou  i rerent  s . 


H ? . The  source  language  will  h*Ve  a single  uniform  comment 
convention.  Comments  will  he  easily  distinguishable  from 
code,  will  be  introduced  by  a single  tor  possibly  two) 
lanruaoe  defined  characters,  will  p'r^it  ary  combination  of 
characters  to  appear,  will  he  able  to  appear  anywhere 
reasonable  in  programs,  will  automatically  terminate  at 


end-of-line  if  not  otherwise  terminated,  and  will  not 
prohibit  autnmatic  reformatting  of  rr^urams.  ....P 

Uniterm  comment  convention  ...................................... P 

Look  different  from  code  T 

Bracketed  by  ore  or  two  characters  .............................. T 

Can  contain  any  characters  ......p 

Can  appear  anv*her»  reasonable  ................................. .P 

Terminated  ty  the  erd  of  the  line  ......F 

Compatible  with  automatic  reformatting  ..........................  I 


The  J3P  language  permits  twe  comment  conventions:  The  comments  can 
either  te  enclosed  between  double  rjuotes  or  they  can  be  enclosed  between 
v sinns.  The  user  can  specify  anvthir.o  in  the  comments  includinr  source 
code  vhich  will  *~e  ignored.  5**Ti-cnlnns  are  not  permitted  in  comments 
‘•'Ut  all  ether  characters  are.  Ccmm»nt*f  re  permitted  anywhere  in  the 
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o r o q r a m except  ir  define  declarations  (Section  ?.2.4>.  Comments  ire  not 
terminated  by  tne  erd  of  line;  msteao  ttey  are  continued  ov*r  the  linp 
and  trtr  rr  inated  hy  either  the  rlosiny  double  ruotes  or  the  X si^n.  The 
comment  ccnventiors  do  not  prohibit  automatic  reformatting  of  rmcirans. 

The  lanouane  will  have  to  dror  one  of  the  two  set?  o*  marks  to 
provide  *r>r  one  single  uniform  comment  convention.  It  shculd  permit 
inclusion  of  fill  lannuane  oefined  characters  ircludinj  the  semi-colon. 
Tte  cements  should  be  allowed  to  aroear  at  a suitable  place  within  the 
Otfine  rec  lar  ations . Comir.ent  s should  be  allowed  to  he  terminated  ny  the 
end  o*  lire. 

I'M  ler.entat  inn  rt  these  chances  in  the  comment  convent  ionr  cl  the 
lannuane  will  require  minimal  ch^n^es  ir  existiro  imp  l e^ert^t  ir  ns  in  t-hr 
area  of  lexical  analysis. 


h®  . Tie  hnruanr  will  ret  rrrmit  unmatched  parentheses  of 
anyhind.  . . . . T 


J requires  matching,  orenin'’  A"d  closinu  parentheses  as  well  as 
PFCINs  and  tnDs. 

to  contlict  with  other  reoui r»tfrt« . 


H9 . There  will  he  a uniterr  retcrert  notation. 


J’f  syntax  for  array  and  tatle  reference  is  identical  to  that  of 
its  internal  function  calls.  Ttey  all  utilize  parentheses  alter  the 
array,  tatle,  or  function  narr  (Sections  9,  4.;*  arc  4.4).  ^ut  whereas 
the  arrays  are  permitted  to  appear  or,  either  the  left  hard  or  the  ri  qht 
hand  side  of  an  assignment  statement,  ^unctions  are  restricted  only  on 
the  riant  hand  side  of  the  assignment  statement. 

However,  tte  lancuaqn  alsc  permits  pseudo  variatles,  which  can 
appear  cn  the  left  hard  side  of  an  assignment  statement.  (pp.  9-1) 

Tc  truly  mret  this  requirement  the  lanonaoe  must  require  that  all 
functions  te  capable  of  use  as  a pseudo  variable  and  capable  rf  Deino 
nut  on  the  left  hand  side  of  the  assionment  statement. 

Tft  implementation  ot  these  changes  will  require  moderate  amount  of 
change*  in  the  dr sice  of  library  functions,  procedures  and  assionment 

stfitpmt  r ts. 
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Hl'j.  Vj  Unquaie  defined  symbols  aprearino  in  the  sa^e 
context  fci l l Have  essentially  different  ir.eaninqs.  ....p 


Ir  neneral,  lannuaoe  symbols  Have  uninue  usaoe,  but  there  are  some 
evcerticns.  *or  exsjrr  le,  the  = s i on  is  used  both  for  assion^ent  and  as 
a test  for  eouality  in  conditional  expressions.  (fecticr.s  *>.*  and  5.3) 

P cistinct  sinn  tor  the  assignment  operation  shoulo  he  irclubed  in 
the  l^o-'.jrjfjj.. 

minimal  changes  will  be  required  to  implement  this  chanqe  in 
existir-  compilers. 
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II.  T Ii *» r e will  he  ro  defaults  in  | ronrams  which  affect  the 
pro.rarr.  logic.  That  is,  decisions  which  affect  proqram  locic 
ail  l be  made  either  irrevocably  when  the  l anpuaoe  is  defined 
or  nypiicitly  in  each  prooran. 


3(.st  defaults  attectinu  proqram  loaic  are  specified  in  the 
reference  nanual  ,ith  few  exc“ptirns.  for  example,  the  SWITCH  statement 
does  net  contain  the  CTHFPt-'lSE  clause  (Section  5.4.3).  Hence  the 
i*K  lementors  decide  where  the  control  will  t c transferred  if  the  value 
of  the  index  exceeds  the  nurber  of  labels  pres°nt  in  the  SWITCH. 
Similarly,  since  no  exception  cortrol  statements  are  orovideo  in  the 
Isnufl’t,  the  implementation  determines  -hat  to  do  or  where  to  transfer 
tre  ccntrnl  after  an  overt  lo*.  or  •?  hardware  interrurt. 

The  SwTTCH  Statement  should  ' c modified  to  provide  for  OTHERWISE  or 
OUT  clause.  Exception  control  statements  should  be  adoed  to  the 
1 1 nq u<» » to  allow'  the  user  to  control  th*  flow  of  proor-'m  in  the  event 
of  an  ioterrutt.  8 moderate  amount  of  effort  will  be  required  to  extend 
the  existin'1  i mp  l en^ntc  t i cos  to  include  these  capabilities. 


I?.  Defaults  will  bn  provideo  fc'  special  capabilities 
affection  orilv  object  rer  resent?  t icn  and  otler  properties 
which  the  programmer  does  not  knou  nr  care  about.  ^t:cn 
defaults  -ill  always  mean  that  the  programmer  does  not  care 
whirl'  choice  is  made.  The  programmer  »>i  1 1 fce  able  to 


overrice  these  defaults  when  necessary-  ....h 

Defaults  specified  for  don't  care  cas*s  T 

Programmer  can  override  the  defaults  F 


The  language  provides  fnr  a laree  number  of  defaults  to  be  hanlled 
by  implementations.  Seme  of  these  are  don't  care  type  of  defaults  e.*., 
r ep resent  at i on  of  data,  treating  a routine  as  CLOSED  if  I Ni I N r option  is 
not  srecified,  and  tmatinr  r procedure  as  non-reentrant  it  the  user 
does  not  srecify  the  RENT  nrticr.  Other  defaults,  such  as  the  ones 
listed  in  II  are  rot  "don't  cane"  type  of  defaults.  Th*  rroframmer  ooes 
not  have  the  facility  to  nverridf  those  types  of  defaults. 

Err  the  scope  of  the  needed  modifications,  see  II. 


13.  The  usrr  will  he  a h I r to  ■’ssociate  compile  tim* 
variaules  with  programs.  These  will  include  variables  which 
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specify  the  object  confute r model  and  other  aspects  ot  the 
ohiect  machine  configuration. 


r 


the  language  does  not  rrovide  for  selective  compilation  depending 
uoon  the  value  of  certain  control  variables,  as  specified  in  the 
requi cement . 

Tn  t ally  provide  tor  ccndi ti ona I compilation  facility,  the  user 
should  be  able  to  specify  the  name  and  con t i -,ur a t ion  of  object  computer 
including  its  memory  size  and  special  hardware  leatures.  These  should 
he  taKer  into  account  durinc  the  crde  generation  process  by  the 
compi  Ur. 

vrderate  chances,  inrludino  Aere  to  specify  these  variables  in  the 
nroor'-o*,  their  syntax  etc.,  ang  tbp  type  of  code  to  te  generated  for 
each  option  will  U ve  to  be  made  in  the  existing  compilers. 


I A . The  source  language  will  permit  the  use  of  conditional 
statements  (e  .0  . , case  statements)  dependent  on  the  object 
environment  and  other  compile  time  variables.  In  such  cases 
the  conditional  will  be  evaluated  at  compile  time  and  only 
the  selected  nath  will  be  compiled.  ...,T 


J i»  permits  conditional  compilation  using  conditional  control 
structures.  The  syntax  of  I f statement  in  J 3P  is  as  tollows  + 

IF  bit  formula;  statement  IFLSE  statementl; 

If  bit  formula  is  a bit  constant  or  a bit  constant  relational  whose 
value  is  not  all  zero,  then  the  statement  following  the  semicolon  is 
compiled,  otherwise  not.  If  an  fLSE  is  present,  only  one  cf  the 
statements  preceding  am  following  the  ELSE  is  compiled.  The  statement 
preceding  the  TLSE  is  compiled  v^en  the  bit  constant  nr  hit  constant 
relational  value  is  not  all  zero  tits;  otherwise  the  statement  followinu 
the  ELSE  is  comoiled.  fr p.  5-2')) 

Not  compiling  a statement  means  that  syntax  checking  is  performed  , 
hut  code  is  not  generated  for  th?t  statement. 

*’o  conflict  with  otter  rerun  rcmert  s . This  facility  can  ne  extended 
to  SvlTfH  statement  also  for  ron'-tant  values  cf  the  index. 
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I 5 . The  source  lanouaoe  ►'ill  contain  a simple  clearly 
identi4iable  base  or  kernel  wlich  houses  all  the  power  of  the 
len^tiaie.  To  the  evfent  possible,  the  base  will  te  r i ri  rr  ■>  l 
with  each  feature  p rovidipe  a simile  unirue  cat  ability  rot 
otherwise  riut  l i cat  ed  in  the  tase.  The  choice  of  the  hose 
will  not  detract  from  the  efficiency,  *-nfety,  or 
jr'Vr  s t aodnb  i l l 1 v nf  the  lani’ince.  ....£*♦ 


1 he  J n lanouaoe  spec  i f i cat  i r,rs  rerresent  the  kernel.  cf  the 
landuaue.  There  are  no  tec  features  which  duplicate  each  other's 
capabilities  with  t*-e  possible  exception  of  rLOF,*L  end  rpmPOOL  scope 
definitions  fop  v^riarles.  a variable  c -n  he  cither  t U.rro  in  a COMPOOL 
or  have  the  f|0D*L  scope,  and  both  options  'will  hjve  the  sre  effect. 
Hence  the  lanouaoe  nt^rly  meets  this  recrircuent . 

A redefinition  of  capabilities  o4  foMpoOL  end  tLOh^l  scores  car, 
elimirrte  redundancies  in  the  lennuaoe. 

virinal  chan  es  will  he  reouired  to  implement  the«-e  modifications 
in  the  exisfim  compilers. 


Ifi.  Lannuacie  restrictions  whir''  are  dependent  only  on  the 
translrter  and  not  on  the  object  rnchine  will  he  specified 
These  descriptions  will  be  optional  and  encapsulated  and  will 
be  distinct  from  the  looical  description.  The  user  will  ue 
exflicitly  in  the  lannuaoe  definition.  ....P 


The  lanqua-’C  specifications  do  not  specify  the  maximum  level  of 
nestinn  in  loops,  the  maximum  number  of  variables  that  can  he  defined, 
the  Tii/iTiH  numher  of  sutreutinrs  allowed,  number  04  nested  -irentheses 
levels  in  expressions,  etc.  It  does,  however,  put  3 limit  o the  size 
of  the  variable  name  (c  alphanumeric  characters),  numt  e>-  of  array 
dimensions  <J)  etc.  (Sections  S , 4.4).  Ttus  it  rertiallv  meets  this 

requirement. 

Tke  specifications  shrulo  r«*t  unrer  limits  on  several  lactors 
listed  above  rather  tfar  leavir'’  them  imp  lC"en*at  ior  dependent.  These 
limits  should  le  reasonably  bjeh. 

Imrlem»ntation  of  these  l a nonage  specified  lirits  will  require 
minimal  changes  ir.  e*istino  ermrilers. 
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17.  Lsnnuafje  restrictions  which  ire  inherently  dependent 
only  on  the  obiect  environment  will  not  be  built  into  the 
lar'juaoe  definition  nr  any  translator.  ....T 


J 3 r language  does  not  contain  features  which  are  dependent  upon 
object  time  environment  (e.:'!.,  core  size,  number  of  r^riohera l devices, 
etc.) 

Mo  conflict  with  other  requirements. 
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J1.  The  lanjuiue  sn d its  translators  will  not  impose  run 
t i r * costs  for  unneedeo  or  unused  Generality.  They  will  be 


c?ta  Ip  of  r-rr^ucino  efficient  code  for  all  proorars.  ....T 

No  efficiency  cost  for  unused  feature*  .....1 

Efficient  code  can  he  rrrriured  for  all  features  ............. ....T 


The  lannuane  design  is  such  that  there  is  no  overhead  in  tcrts  of 
generated  cede  because  of  unused  features.  For  example,  there  is  no 
overbeac  for  rtcurr icr  it  it  is  not  specified  Ly  the  user,  no  ovf rneao 
for  tte  ] N L 1 f r option,  etc. 

*' o conflict  with'  other  recti  rcircnt?  . 


J2.  Any  optimizations  performed  Oy  the  translator  will  not 
chan  [j  e the  effect  of  ttc  prooram.  . . . . T 


The  Jfd  spec i f i cat i nns  an  not  specify  if  the  translator  should 
perform  oc  t i mi  za  t icn  and  bow.  HowPvnr,  the  intent  of  the  requirement  is 
me*  in  lannuacie  s^ec  i t i ca*  i ors . Certain  lancueue  features,  such  as 

INLINE  , conditional  l r for  con>-  i l at  ion,  etc.  do  perrit  npt  i mi  zn  t i on  nf 
cede  or  time  ini  it  is  intended  that  translators  should  rot  chnnne  their 
effort. 

No  conflict  with  other  r eciu  i r t ment  s . 


J3.  The  source  lanquaoe  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  including  machine 
lanouaoe  code  insertions.  ....P+ 


requires  that  machine  rude  he  encarsulated  inside  procedures 
which  can  then  be  called  from  J3f-  procedures  or  nronrans  via  normal 
procedure  invocation  methods.  Machine  code  cannot  be  interspersed 
inline  »ith  J3p  cooe.  However,  the  lanquaue  does  not  reouire  the 
assemiiy  lannuaoe  procedures  to  have  a • reamblf  specifying  such  details 
as  tt  ( name  of  t*e  computer,  cornutrr  word  size,  etc.  This  can, 
however,  he  accomplished  voluntarily  by  the  programmer  via  approoriate 
comments . 

f pardrft orv  procedure  shouM  be  ertal  lished  renuirinq  machine 
laopuafe  rroce^ures  to  specify  the  name,  size,  word  size  and  other 
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detail*;  of  the  hardware  ertvi  rcnn  ent . This  will  provide  readability  of 
machine  dependent  routines  and  make  thnir  encapsulation  complete. 

viniral  changes  in  existing  i mp  lement  at  i on  will  be  reauired  to 
incorporate  this  language  modification.  The  entire  preamble  can  be 
treated  like  a comment. 


JA.  It  will  le  rossitle  within  tie  source  language  tr 
specify  the  obiect  iresentation  of  ccnposite  data  structures, 
able  to  specify  the  ti'xe/snace  trade-off  to  the  translator. 


If  rot  specified,  the  otject  renresentat ion  will  be  optimal 
as  determined  i y the  translator.  ....d 

Encapsulated  specification  of  representation  possible  .......... ..P 

Space/time  tradeoff  can  be  specified  .P 

J3H  allows  a data  packinc  factor  to  be  specified  in  its  table 


declarations  whirr  permits  a user  to  have  no  racking  (N),  medium,  packing 
(**)  or  dense  nackino  m of  data  (Section  A. 3).  However,  no  other 
exrlicit  optior  is  available  to  provide  the  translator  with  the 
specifics  of  data  rer resentat ion. 

Certain  other  language  features  allow  the  user  to  control  the 
space/tine  trade  o<f  . These  include  INLINE  option  (which  can  save  time 
at  the  ex;  erse  of  space),  RFM  cttior  in  procedures  (not  specifying  this 
option  will  save  core  space  by  generrtino  non  reentrant  code)  and  IF 
conditional  compile  (which  saves  both  time  *nd  space).  However,  no 
lanauaue  defined  directive  is  available  which  instructs  the  translator 
to  consistently  generate  code  to  save  time  or  space  whenever  and 
wherevtr  possible  throughout  the  process  of  compilation. 

I enouage  defined  directives  to  the  translator  should  he  introduced 
which  can  srecity  certain  formats  for  data  before  it  is  transferred  to 
an  I/O  aevice  or  another  computer.  These  directives  should  also  specify 
whether  the  user  wishes  tc  have  code  generated  which  will  attemot  to 
save  execution  ti*e  or  core  sp'ace  wherever  possible. 

Implementation  rf  these  capabilities  will  reouire  modifications  to 
existing  compilers  to  accept  larouacte  specified  directives,  in  the  area 
of  I/O  to  be  able  tr  accent  or  transmit  data  in  specified  formats  an^  in 
the  areas  of  code  opt i mi ? at i or  . 


JS.  The  programmer  will  be  alle  to  soecifv  whether  calls  on 


! 
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a routine  arc  to  have  an  nrcr,  or  closer!  implementation.  An 
oper  and  a closed  routine  of  the  sare  description  will  have 
identical  semantics. 


Coen /c  l osed  properties  car  be 
Open  and  closed  versions  have 


spec ified  

the  same  semantics 


The  JMI*r  .ittritute  remits  a library  procedure  to  te  included  in 
the  u 'pr  code  at  the  point  of  invocation.  If  this  option  is  not 
specified  then  the  procedures  are  treater  as  closed. 

Vo  conflict  >itb  other  requirements. 
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L*tr?r»*pus  fpsturfs 

*e  recommend  that  the  following  features  of  JOVIAL  J3E, 
reojirfO  by  the  Tinman,  be  kept: 

* The  use  of  bit  strings. 

* Compiler  directives  for  table  packing  (none,  medium, 
or  ^ensr ) . 

* LIKE  table  definition.  This  same  effect  could  he 
obtained  ty  other  means  if  J 3P-  were  extended  t" 
include  a type  definition  facility. 

* Certain  pseudo  variables  (functions)  which  can  be  u^ed 
nn  the  lett  hand  side  nf  an  assinnment  statement.  ror 
examol",  the  NEXT  functional  modifier. 


We  recommend  that  the  following  features  of  JOVIAL  J 3t  , 
required  tv  tb"*  Tinman,  be  deleted: 

* Double  precision  floating  point.  This  capability 
would  assumed  by  the  precision  specification  in  any 
extension  nf  tKe  lar^u.ne  alcnr  the  Tinman  lines. 

* The  NWDSEN  functional  modifier,  which  returns  the  size 
of  a table  in  words.  This  is  too  hardware  deoendent. 

* OVERLAY,  a form  rf  free  union. 

* byte  tyre  data.  TMs  is  too  hardware  dependent. 


Fummar  y 


.) /r  is  « sm-ill  .'itt  many  modern,  useful  features.  Clarity 

and  ten*!  i iterev  of  lanriuac.e  feature  has  beer  emphasized  throughout  the 
language  definition.  T^e  lanouare  provides  for  frur  levtlt  of  scopes 
(SYST  rv,  C'WhOOL,  GLOH*l,  anri  LhC*L)  anH  specifies  rules  tor  resolution 
of  con+lirts  related  to  levels  d scores  of  variables,  data,  nroredures, 
cU  . t CAPY  o : tiro  is  rrnvict’d  as  a compile  tine  facility  ti  insert 
program  twxt  f re.  external  sources.  The  language  also  emphasize*- 
ro'rr i l c-t i ne  cfecks,  whenever  wherever  possible,  thus  pruvidirrs  tor 

debugging  in  early  stages  of  program  deve  l op  "ent . It  requires  typo 
checkin.  on  procedure  parameters  and  distinguishes  between  inf  it  and 
output  r arameters . It  requires  evaluation  of  constant  expressions  at 
cornilr  *-irie.  heclaration  for  all  variables,  tables,  records,  jnr1 

arrays  • ave  to  h°  evpiicit  anH  should  he  before  use.  * pointer 
Teebaoi  is  provided  in  the  language.  *n  uncommon  feature  in  the 

Imiuaoe  is  conditional  coir(iln,,'inn  of  IF  stoterent,  in  which  the 

constant  condition  is  evaluated  at  cG"-pil“  tine  and  cole  is  generated 
only  for  that  portion  ct  the  condition  which  will  be  executed  during 
execution  tirre.  fi  capability  + or  specifying  that  a procedure  is  to  be 
co  uni  | rn  in  open  forf  is  also  available  fINLIN>r  option). 


however,  there  are  several  characteri st i cs  ir  which  the  language  is 
lackin'  ,.nrl  fails  to  measure  ui  to  the  tinner  recu  i rcrent  s . Thp 
Umu?1'?  does  not  provide  tor  cefinition  of  new  data  types  or  new 
operators.  It  "<oes  not  provide  tor  features  supporting  real-time 
!:rocessirf’,  parallel  irocessinr,  or  exception  handling.  Vo  provision 
has  b<en  m»He  for  input /output , dynamic  array  allocation,  truncation  of 
results  f ron  the  right  instead  of  Iron  t>e  left,  or  explicit  instead  of 
implicit  fata  conversion.  Faroe  mo  precision  spe c i f i cat  ions  *or 
variatl'-s  *re  net  supported.  The  user  Goes  not  have  tie  facility  to 
-*efire  procedures  with  a variable  number  of  parameters.  Procedures  may 
not  te  recursive. 


bespit  e the  lack  of  many  essential  qualities  specified  dv  the 
Tinman  r eon i r enr rt ? , jtn  contains  many  fine  characteristics.  The 
existini  kernel  of  the  languaoe  is  small  and  contains  features  which  can 
‘-e  discorded,  modified,  rr  ex;  anded,  tc  meet  the  tirn&n  requirement.  To 
idn  the  mission  cor  abilities  to  the  language  definition  and  to  implement 
them  are  tasks  of  major  proportions,  but  they  have  a reasonable  chance 
of  success..  »'o»ever,  suet  efforts  cannot  ouarartpe  a clean,  consistent, 
and  simple  hnrusut.  Starting  from  scratch  would  be  a better  approach 
bo  oltrin  th»se  cl aracteristics  . 
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lntmduct  ion 

T^is  reoort  Tives  a comparison  of  ftp  lannuatie  JOVIAL  J73  (Level  I) 
to  t'*  l iivruri  Is^guaae  requi  recent  s (Department  of  Defense  ^ ertui  r emeot  s 
for  H (ncr  Computer  F rnq ramming  Languages,  "Tinman"  - 1 larch  1976, 

becri)>  IV).  (nr  the  purposes  of  this  cor pari  son,  JOVIAL  J 7i  (Level  I) 
is  rr'-siPered  tc  he  defined  ly: 

JOVIAL  J73/1  St.ec  if  ication 
July,  1 v 7 6 

Kerne  »ir  Defense  (enter 

Tinmen  contains  7f  lanaqaoe  r eoui r^mer  t c . This  report  compares 

JOVIAL  J73  (Level  T)  to  each  requirement  individually.  If  a requirement 
is  totally  satisfied,  the  Rcco-narvin'-  text  is  a summary  o4  the 

particular  mechanism  used.  (Pccas  ions  1 1 y no  tcxt  is  reeded  if  a 

requi re  tent  is  totally  satisfied.)  If  u r equi  rement  is  not  totally 

satisfied,  the  text  consists  of  a summury  of  the  short cr m inns  ano  such 
items  as  tie  scope  of  the  changes  necessary  tc  fully  reet  the 
r equi  r ?'  er  t and  the  impact  nf  these  chanues  on  existiro  imp  lerent  «■  t i ons  . 

ruch  Tinman  reauiremert  begins  with  an  introductory  paraaraah. 
These  naragraphs  are  rer  reduced  in  this  report.  In  ^any  cas^s  they  are 
followed  by  several  sir.jlp-line  sumraries  of  features  in  the  area  of  the 
requirement.  Usually  these  are  features  which  are  specifically  called 
for  in  toe  requirement.  A feature  enclosed  in  parentheses,  however,  is 
one  •hich  the  reviewers  thought  possibly  desirable,  even  though  not 
called  4or  in  the  requirement. 

Svmbnls  placed  beside  the  introductory  poraaraph  and  the  individual 
features  indicate  the  degree  to  which  the  requirement  or  feature  is 
satisfied  by  the  lancuace.  T*-e  symbols  aruf  their  meaninos  are: 

T - Total ly  satis  fieri 

P - partially  satis4ied 

f - Fails  (not  satisfied  at  all) 

U - Unrlear  from  the  documentation 

nt  - Almost  totally  satisfied 

P-  - Pnly  slinbtly  s.atis4ied 

N/A  - Not  applicable  (j*pd  only  for  individual 
f°otures  when  the  requirement  is  not  satisfied 
at  all) 

(Tne  svmDols  l,  f t,  and  P-  .ill  ~tren  be  used  with  re  iinrr  tnt:  which 
are  stated  in  one  of  ftp  forms  "II  rr»  will  *'e  no..."  or  "All...",  even 
though  only  Tor  F are  technically  a p j l i c a b l • in  there  cases.) 
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tv  e ret  ort  concludes  with  tv. «>  summaries.  The  first  is  cf  the 
features  of  J0V1»L  J75  (Level  I>  which  are  extraneous  to  Tinman  and  the 
desirability  of  retaining  each  of  them.  The  second  is  of  the  lanjuaqc 
as  a jfio l e and  th«  desirability  of  mooifyino  it  to  brino  in  into  line 
(«itn  toe  Tirnan  r®aui  rement  s . 


JO  VI 'l  J?'/I 
? p a u i r * " e n t A 1 


1 


*1.  T^e  lanousae  will  t «•  typed.  Th»  tyre  (or  rode)  of  *11 
vsri.ibles*  components  of  c omnor  i t e da  to  structures, 
?v.  r?  ssions,  ooerat ions , and  parameters  will  be  determinable 
at  compile  tine  and  unalterable  at  run  tine.  The  lannu&'ie 
■will  n tjuire  t*at  thr  *voe  of  each  variable  anc*  component  of 
corrcsite  data  structures  be  explicitly  specified  in  the 
source  (roe rans. 


v-  ‘ i l ° J'3  is  tvred  in  tb  ° sense  ♦’hat  tyres  «re  Incsn  ?t  compile 
tine,  certain  lannuaue  features  allow  the  defeat  rt  t vpe  cbeckin-j 
auainst  weich  the  romp.iler  cannot  rrotect.  Tbe  constructs  OVERLAY, 
based  veriahles,  rnd  specified  tables  essentially  implement  free  unions, 
and  sirce  there  is  no  requirement  (nor,  in  fee<,  npy  l?o'-i *ja'-e  art  ifact) 
to  discriminate  ancm  the  union  tyres,  the  full  inttot  of  A1  is  not 
satisfied  in  J?3.  factions  1 ard  ?) 

Tht  elimination  of  PVEPLAY  is  trivi'l  and  has  no  imnact  on  other 
features;  the  effect  unor  imnierentations  is  not  known,  but  where 
D V E R L f Y is  used  ^especially  absolute  overlays  for  svstem  allocation), 
its  elimination  could  be  painful  bo  circumvent. 

C3*.ec  variables  coulc  b*>  eliminated  or  chanqed  to  conform  to  Tinman 
"pointer  f roperty"  specifications  — decidedly  expensive  (see  or ) . 

Specified  tables  could  be  eliminate d,  but  this  impacts  JA,  and 
would  severely  irrract  the  e»tar«-  J73/T  compilers  (namely,  hFC-11,  HPC, 
and  S A a s 0 Fault-Tolerant  J73*s)  which  make  heavy  use  of  specified  rabies 
to  nptir.ipe  table  space  usaoe. 


A2.  The  lannuaqe  will  provide  data  tvnes  for  inteaer,  real 
( f I r at i no  print  and  fixed  point),  Poolear  and  character  and 


will  rrovide  arrays  (i.t.,  composite  date  structures  with 
indexable  components  of  biomrqenenus  type)  and  records  (i.e., 
comonsite  data  structures  ..ith  labeled  components  of 
hr  t**roqeneous  tyre)  as  tyre  nmer&tors. 

Intn  er  .................T 

flnatim  point  T 

Fixe4  point  ...f 

Bonl'An  P 

Character  Strinn  T 

Arrays  

Records  i’ 


1 or  Iran  --  Here  is  no  Pcolran  tyre  as  sorb  in  J 7T.  However,  the 

effect  of  roolear.  is  implemented  tbrouof  the  use  of  type  "lit"  in  which 


jovial  j 7 3 / 1 
keoui remert  A? 


? 


the  low-crder  bit  of  a bit  strirui  is  treated  as  "true"  if  a 1 and 
"false"  if  ;).  Thus,  tor  examnle,  medicates  are  evaluated  to  tyae  bit 
of  size  one  rather  than  to  the  conventional  type  boolean. 

t mays  and  Records  — J7*  permits  bfth  arrays  (called  TABIFs)  and 
records  (also  called  TAPLFs).  However,  while  one  can  declare  an  array 
of  records  (that's  exactly  what  a TAfiLF  is),  one  cannot  declare  records 
containing  arrays.  Furthermore,  J 73  does  not  support  the  potion  of 
, rctotvpe  definitions  (tTDF  in  A L C> P L rr  "type"  ir  PASCAL),  such  that 
"type  uererators"  as  called  for  in  A?  arc  not  fully  suroorteo. 

The  addition  of  records  of  arrays  and  prototype  detinitions  to  J7< 
is  a najer  extension  anct  would  greatly  effect  existing  compiler  aesign. 
Since  type  generation  is  unknown  to  J73,  existing  compilers  assume  a 
fixed  number  of  pre-defired  types  in  the  symbol  table  desicn,  and 
ltntrali2iro  tyre  definition  is  therefore  r.  fundariental  and  costly 
change.  Syntactically,  one  can  see  that  the  addition  of  prototypes  is 
somewhat  clumsy  owinq  to  the  fact  that  J73  declarations  contain  orooerty 
descriotions  that  are  scattered  about  the  declaration.  To  some  cegree, 
o arameter  i zed  defines  may  be  useri  to  effect  prototype  definitions. 
Decords  of  arrays  are  mere  difficult  because  of  the  unique  namion 
conventions  of  J 7 3 and  the  lack  of  provision  for  field  selection  bv 
nullification. 


*3.  The  source  larruaae  will  renuire  global  (to  a scope) 
specification  of  the  precision  for  floatinn  poirt  arithmetic 
and  will  permit  precision  specification  fer  individual 
variables.  This  specification  will  be  interpreted  as  the 
maximum  precision  required  by  the  proaratr  looic  and  the 


minimum  precision  to  be  supported  by  the  ohiect  code.  ,...P 

Global  arithmetic  precision  specification  manoatory  .............  f 

Individual  variable  precision  specification  permitted  ...........T 


Flnatim  point  precision  is  specified  in  the  type  declaration  for 
individual  variables  h y stating  the  mantissa  size  ir  bits.  Thus, 

T T F * FF  F c7 

declares  a floatinn  mint  variable  eecuirinc  a minimum  of  ?7  bits 
(excludino  sinn)  to  express  the  mantissa.  The  precision  mav  be  omitted, 
and  the  compiler  supplies  a default  "« inq le -prec i s i on"  value  that  is 
t aroet-machine  dependent.  (?.1.3.7) 

* clobal  floatin'  point  specification  would  affect  only  those 
variables  with  the  default  precision.  The  implementation  impact  is 
trivial. 
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A4.  fixed  point  numbers  will  he  tr°ated  as  exact  ouantities 
which  have  a ran^e  and  a fractional  step  size  which  are 
determined  bv  the  user  at  compile  tire.  'cale  factor 
*ann':»'ient  will  be  done  hv  the  compiler.  ....f 

treated  as  exact  nuontities  t /A 

Ka rye  and  step  size  determined  at  roTrile  tine  ................. .N/A 

Scaling  handled  autom  at  i ca  I l y ,N /A 


! 


I 


J does  not  support  fixed  taint  in  level  I.  (Sections  1 and  ? ) 

The  full  lannuaoe  J ?i  includes  fixed  point,  and  presumably  the 
exclusion  of  fixed  point  from  level  T reflects  a concern  for 
imr  l entrt  at  ion  erst  only.  Clearly,  the  full  langtiaoe  f i x e d-noint 
canaDility  could  he  drawn  into  a level  1.5  sut set  without  a question  of 
langujoe  consistency.  The  isu.net  on  existing  compilers  may  be  exrecten 
tc  be  roderate. 


AS.  Character  sets  will  be  treated  a-  any  other  enumeration 


type.  f 

New  sots  can  be  defined  as  enumeration  types  ....................  F 

ASCII  end  fcRfPIC  are  r rovi ded  ...................................  r 

(Conversion  capability  between  sets  is  available)  f 


J 77  defines  the  character  type  as  a built-in  type.  The  J 7 5 
character  type  is  really  a character  string  type  whose  size  is  fixed  at 
tne  declaration.  the  admissible  literal  denotations  tor  character  tvne 
are  drawn  from  a larue  set  of  qrarhics  whose  ordering  is 
i^D l ement at icn-derendrnt . (1.7.1.?,  ?.1.3.?> 

The  addition  of  enumerated  character  types  may  b«*  seen  as  an 
extension  of  th*  J 75  status  list  (the  only  form  of  enumeration  type  in 
the  language).  ASCII  and  FITCDIC  covM  then  he  added  as  nreoefined 
enumerations,  and  conversions  coulc  be  added,  all  ct  mooest  impact  on 
existim  implementations  . 


»*>.  The  language  will  reguire  jut  specification  nf  *he 
nutter  of  dimenriens,  the  ra-ne  of  subscript  values  tor  each 
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dimension,  and  tyre  of  each  array  comronent.  The  number  of 
dimensions,  the  tyDe  and  the  lower  subscript  bound  will  be 
determinable  at  comrile  time.  The  uoner  subscript  bound  will 


be  determinable  at  entry  to  the  array  allocation  scope.  ....! 

Number  of  dimensions  is  fixed  at  compile  time  .1 

Type  is  fixed  at  compile  time  ..............T 

Lower  subscript  bound  is  fixed  at  compile  time  T 

Upper  subscriot  bound  is  fixca  at  sc^ie  entry  .......  .u 

Subscripts  only  integers  or  Iron  an  enumeration  tyre  ........... .P 

Subscripts  will  be  from  a contiauous  range  .....T 


All  -.rray  subscripts  are  fixed  at  compile  time.  Subscripts  are 
confined  to  iriteqer  or  status  tvpe  (which  are  otherwise  treated  as 
integers).  J 23  does  not  allow  character  types  as  subscripts  (except  in 
an  exrlicit  type  conversion  to  ir.teoer  which  is  the  character’s  internal 
Dit  rer resent  at  ion) , and  since  Tinman  renuires  that  character  tyoe  be 
enumerated,  J 77  partially  fails  this  requirement.  (P.1.5) 

Addino  variable  upper  bounds  to  arrays  will  affect  existing 
implement ations  in  which  data  allocation  is  fixed  at  compile 
time  — moderate  innut.  Addino  character  types  as  subscripts  requires 
the  implementation  of  character  tvne  by  enumeration  (see  A5)  and  a 
fundamental  change  in  the  way  sutscripts  are  syntactically  t.houoht  of  in 
J73  --  they  are  now  simrly  inteoers  ■*-  ami  in  the  way  in  which  the 
enumeration  type  is  conceived  --  they  are  now  simply  mnemonic  integers. 
The  intent  of  A*  could  be  met  bv  includir.o  in  the  table  declaration  the 
subscrirt  type  (much  as  PASCAL  does)  tc  include  integer,  status  or 
character. 


A 7 . The  lanouaoe  will  rermit  records  to  have  alternative 
structures,  each  of  which  is  fixed  at  compile  timie.  The  name 
and  type  of  each  record  component  will  be  specitied  by  the 


user  at  compile  time.  ....P 

Alternative  structures  for  records  art  possible  H 

r i r r i mi  na  t i on  condition  may  te  any  Roolf an  expression  ..........P 


Alternative  structures  are  implemented  through  specified  tables, 
ba«ed  variables,  or  PVFRLAY.  hi s cri mi na t i on  is  entirely  by  convention, 
there  are  no  lan-juatie  constructs  to  facilitate  discrimination,  and 
arbitrary  references  to  memory  are  sirnplv  achieved.  (2.1.5) 


i 


The  concent  of  discr imirat im  is  so  tnreinn  to  J77  that  to  modify 
the  lanouaoe  to  include  it  is  essential!/  to  "dine  a new  lanouaoe.  The 
reoui  remer.t  in  A7  impacts  the  three  lanouaoe  features  (specified  tables. 
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bared  variables,  anrt  overlay)  rone  of  which  is  trivially  modifiable  to 
achieve  the  intent  of  A7. 
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PI.  As  s ignment  3rd  reference  operation  will  he  automatically 
defined  for  all  data  tyt.es  which  do  not  manage  their  data 
storage.  The  jssimment  operation  will  permit  ary  value  of  a 
liven  type  to  be  assigned  to  a variable,  array,  or  record 
co’i[  onent  of  that  type  or  of  a urion  type  containino  th<-t 


tyoe.  Reference  will  retrieve  the  last  assigned  value.  ....F 

Automatically  defined  for  ary  type  (excert...)  ................. .P 

Available  for  inoividual  components  I 

(Assignment  and  reference  via  functions)  P 


Assignment  arc*  reference  are  not  consistently  defined:  Type 
matching  is  not  imposed  for  structure  assinrnert  nr  parameter  passim 
and  whole  arrays  are  not  assiqraMr  (only  entries  of  TAPLFs,  that  is, 
inrividual  instances  of  a structure).  Assignment  art  reference  are 
defined  for  si^rle  items  (i.e.,  non-record,  non-array  types). 
Assignment  to  union  types  is  net  nossible  because  union  type  is  not 
define u i r J 7 3 . 

(Reference  by  turction  is  possible,  except  that  only  primitive 
types  are  definable  as  function  "results".  For  example,  one  cannot 
define  a function  which  yields  ? component  of  a record  or  cf  an  array  or 
that  yields  a record  or  an  array.  (unctions  on  the  le tt-hard-s ide  are 
not  definable,  but  certain  built-in  functions  may  he  used  or  the  left: 
Pit,  BYTE.) 


The  implementation  of  consistent  assignment  end  reference  is  an 
enormous  chanqe  to  J73,  especially  to  pprmit  array  assignment  ana  to  add 
all  tvpes  as  function  results  (wfich  we  construe  as  essential  to  the 
notior  of  consistent  reference).  Complete  consistency  arques  for  jser- 
»fina..  le  lef  t-hana-s.ide  functions  to  supplement  °IT  and  rYTE,  but 
mechanizing  these  is  beyond  the  scope  of  this  study. 


P2.  The  source  lanauage  will  have  a built-in  operation  which 
can  he  used  to  compare  any  two  data  objects  (regardless  of 
type)  for  identity.  ....m 


Array  types  may  not  he  compared,  and  type  matching  is  not  imposed 
for  record  comparison  such  that,  tor  example,  a table  entry  containing  a 
character  and  a real  may  he  found  equivalent  to  an  integer.  (A. 4,  4.5, 
4.*,  4.7) 

there  will  be  a minimal  impact  to  include  array  comparisons,  hut  3 
major  imrmet  to  include  type  rhecVino  for  records  (althounh  this  is  a 
problem  that  mijst,  in  general,  he  solved  if  J/T  were  to  meet  the  most 
fundamental  irtent  of  Tinman). 
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Q3.  Relational  operations  will  be  automatically  defined  4nr 


numeric  data  ard  <.  I l tyres  defired  by  enumeration.  ....P+ 

built-in  tor  all  numeric  and  enumeration  types  T 

Ordering  can  be  inhibited  when  desired  .......F 

Relational  operators  <,  >,  < = , >- , - , <>  apply  to  all  njrmic  types 
includir j "status"  types.  Unordered  sets  unknown  in  J/7.  (4.4,  4.S, 

4.6,  4.?). 


B4.  The  built-in  arithmetic  operations  will  include: 
addition,  subtraction,  mul t i p l i cat i on,  division  (with  a real 
result',  exponentiation,  integer  division  (with  inteoer  or 
fixec  point  arguments  am  remainder),  and  negation. 


Addition  T 

Subtraction  . . . . I 

multiplication  T 

Division  with  real  result  .T 

exncnentiation  ...........T 

Integer  and  fixed  point  division  with  remainder  ................. f»+ 

Negation  T 


Primitive  operations  use  familiar  notation  (♦,  -,  *,  /).  Division 
with  real  result  occurs  whenever  at  ln?st  on®  of  the  divide  operands  is 
real;  division  between  integers  produces  an  inteoer  result.  A special 
operator  (\)  yields  the  reminder  of  an  integer  (cr  real)  division. 
( 4.3) 

(Nrte:  Because  fiveu  point  is  not  supported  in  J77,  there  is  no 
fixed  mint  division  with  remainder.) 


PS.  Arithmetic  ?r.d  assi'r-en*  operations  on  data  which  «re 
within  the  ranee  specifications  of  the  procram  will  never 
truncate  the  most  significant  dinits  of  a numeric  quantity. 
Truncation  =>nd  roundim  will  alwavs  be  on  the  least 

significant  oiiits  and  will  never  he  implicit  tor  integers 
and  fixed  point  numbers.  Implicit  rourdina  beyond  the 
specified  precision  will  be  allowed  for  4lr«tino  ’*nint 
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Never  from  the  left  for  data  within  range  ? 

Never  on  the  riqht  lor  inteoer  and  fired  roint  F 

Implicit  floating  point  roundinr  beyond  precision  allowed  ....... T 

(Run  time  checks  can  be  avoided)  . . N / A 


Assuming  that  "data  within  ramie"  excludes  intermediate  results 
ttat  may  he  out  of  ranap  (Row  else  do  we  net  truncation?)  then  J73 
truncates  on  the  riqht  by  i^p  lementatior.  convention;  truncation  is  not 
discussed  tor  arithmetic  operations  fxcent  for  assignment  to  floating 
variables  in  which  cne  has  the  option  of  rounoed  or  truncated 
(presumably  low-order).  Right  trunrution  is  always  implicit  tor 
integers. 

Since  truncation  is  net  properly  defined,  left  truncation  could  be 
added  at  modest  i mo  l emrn  fa  f i on  cost.  -«un-tine  checking  could  be  added 
to  correct  the  inteoer  truncation  problem  (hut  with  the  option  for 
disablinn  the  checking  mechanism)  at  moderate  cost  (either  by  inserting 
checking  code  in  the  object  program,  or  by  interrretive  execution  via 
debuoging  data  Generated  as  an  amendment  to  the  object  program). 


pft.  The  built-in  Poolean  operations  will  include  "and", 
"or",  "not",  and  "xor".  The  operations  "and"  and  "or"  on 


scalars  will  Re  evaluated  in  short  circuit  mode.  ....P 

Short-circuit  and  p 

Short-circuit  or  .......P 

Not  T 

Xor  T 


«y  convention,  most  J 73  implementations  employ  short-circuit  mode, 
but  rot  by  language  definition.  (A. 5,  4. ft,  4.7) 


B7.  The  source  Itnouaoe  will  permit  scalar  operations  and 
assignment  on  ccoformahle  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  logical 
structure.  ....P 


Scalar  operations  on  arravs  

assignment  between  records  and  arrays  of  crnformaMe  type  .... 
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J/i  does  not  permit  ajsionrent  or  rf  f erenfp  to  array?  in  *ny 
context  exc^ot  the  na'sir('  a*-,  an  actual  "r^ff  rence"  oarfTeter. 
Assignment  Det^eer  records  is  permittee!  with,  coni  c rmab  i l i t y cetined 
ti?twp‘'r'  any  tw:  record? . That  is,  i-h^re  is  nc  type  ch**ckinc,  and  the 

assignment  is  dy  hit  strino  n an i mu  la*  ion  rather  than  data  equivalence. 
(Section  /. ) 

Tht-re  will  he  a moderate  to  heavy  impact  to  add  array  ass i -o^eot 
ano  reference  with  proper  tyre  checking  and  to  ado  contcrmabi  lity 
checkin*’  tor  records.  FAlsr  discussed  under  requirements  PI  *nd  £<?). 


3h.  T^ere  will  he  no  implicit  type  conversions  hut  no 
conversion  operation  will  he  required  when  the  tyre  of  an 
actual  parameter  is  a constituent  of  ?,  union  type  which  is 
the  formal  parameter.  The  lencuace  will  provide  explicit 
conversion  operations  an.onp  integer,  iixed  point  and  floatir.o 
point  data,  between  the  ohjert  rpnre sent  a t ion  cf  numl ers  and 
th°ir  representations  as  characters,,  and  between  fixed  point 


scale  factors.  ....P 

Ho  implicit  conversions  . . ....1 

Explicit  between  intener,  fixed  point,  and  floating  point  ...... .T 

Explicit  between  fixed  point  scale  factors  ..F 

(fcyplir.it  between  intener  and  Boolean'  ..........................‘(/A 

(Explicit  between  irteaer  and  enumerated  types)  F 

(Explicit  between  differert  enumerated  tyres)  f 


puilt-in  functions  (with  specification  for  excention  conditions) 
are  provided  for  INT,  FlOAT,  CHAP,  and  RIT  cf  types  float,  char, 
s i aned- i nteoe r , uns i need- i nt eoe r , and  bit. 

Tnere  is  no  provision  for  character  representation  of  internal 
numeric  objects  nor  vice-versa. 

Enumeration  type  in  j?5  is  treated  always  as  integer,  thus,  no 
conversion  required  or  defined.  (1.7.1.?) 

There  will  he  a modest  imrnct  to  orovide  the  various  explicit 
conversions. 


•■olirit  corvr rsicn  operations  will 
-•  .•»  numerical  rannes.  There  will  be  a 
t*  « ,•  cn  ar.y  inte;er  or  fixed 


not  t e required 

run  time  exception 
t -pint  value  is 
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ID 


truncated.  ....F 

Implicit  conversion  between  ranees  F 

fxcertion  condition  cn  integer  and  fixed  point  truncation  F 


, Ranges  not  defined. 

. Truncation  not  noted. 

>?ur-time  checks  for  truncation  could  be  added  without  conflict  with 
other  lancuage  features.  (See  P5.) 


Bin.  The  Base  lenouaqe  will  provide  operations  allowino 
programs  to  interact  with  fil^s,  channels,  or  devices, 
including  terminals.  These  operations  will  permit  sending 
and  recrivino  both  data  and  control  information,  will  enable 
oroorams  to  dynamically  assicn  and  reassign  1/0  devices,  will 
provine  user  control  *or  excretion  conditions,  rd  will  nnt 
te  installation  dependent.  ....F 

Sending  and  receiving  of  data  ................................... F 

Sending  and  receiving  of  control  information  ....F 

Dynamic  device  assignment  I 

User  exception  condition  control  ...............F 

Tnstel  lation  i r dependence  ...F 

(Data  formattino  capability)  F 

(Recdino  and  writing  of  bit  striros)  F 


' 


J?3  defines  no  I/O.  (No te:  A non-standard  superset  of  level  1 
i mp l erne rt ed  for  w r i ght -Pat ter son  AFP  Avionics  lab  includes  a FORTRAN  I/O 
like  c apabi l i ty ) . 


bonifications  to  implement  I/O  could  all  be  made  entirely  external 
to  the  lanouace,  i.e.,  the  -mcedur",  function,  table,  arid  compool 
capability  well  provide  all  that  is  reouired  in  P10-  Note  that  the 
sc  'in p and  receiving  of  control  information  is  clearly  so  hardware  and 
ope  tinn  system  dependent  that  it  seems  as  if  this  reauirement  is 
redundant  with  a ?;  that  is,  the  enumeration  tyre  is  sufficient  as  an 
agent  for  the  control  information  transfer,  and  language  artifacts 
beyond  this  orimitive  capability  will  suffer  in  the  attempted  maopinq 
from  real  hardware /syst  errs  to  tKe  Isnouane  constructs. 
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P1 1 . The  Language  will  provide  operations  on 
fefired  as  : ^i»pr  set®  of  enumeration  types  (see 
operations  will  include  union,  intersection, 
conn  ler>ent  , orm  an  element  predicate. 


data  tyres 
Fr).  tf-sc 
f!i  f ference. 


F 


Un  ior  

Intersection  ............'-/A 

Oil  ference  

Corrlerrent  

l*en.herehip  preoicate  ............. .N/ * 

( Set  inclusion)  U/b 


Sets  and  pnver  sets  are  not  defined  in  JYS. 

J ' will  accommodate  the  addition  of  sets  and  rowersets  and  the 
requirec  operations  witn  snl  l impact  on  existing  features  and 
implementations.  Seme  imp le«entaticr  derendent  upper  hound  on  set  size 
mav  he  included  in  e realistic  approach  (say,  w , where  » is  the  word 
size  in  bits),  and  this  parameter  voul*  be  available  as  an  inquiry 
primitive  in  t^e  lanmace. 
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Cl.  *ide  effects  which  are  dependent  on  the  evaluation  order 
atom  the  arcni",ents  of  an  expression  will  re  evaluated 


lef t -t o-r i oht . ....F 

Side  effects  must  occur  in  lef t-to-r ioht  order  ................. .F 

(Fmtedced  a ss i inmert s ) .........F 


The  lanouaqe  is  ecuivocal  on  the  subject.  J73  specifies  that 
"within  a particular  precedence  level,  operations  are  combined  frot  left 
to  rinh.t",  while  later,  "The  evaluation  croer  of  formulas  is  unsoecified 
except  that  address : for * v l a«  and  indices  (subscripts)  must  he  evaluated 
before  variables  with  wnich  they  are  associated  are  referenced".  (4.*) 

•e  take  ♦he  latter  as  the  ycverninu  specification. 

There  is  no  lanouaqe  iTpact  in  specifyinn  left-to-r iqht  evaluation 
order  of  expressions  rr  formulas  (side  effects  are  occasioned,  not 
evaluated);  however,  existirc  compilers  will  rcouire  modification  to 
enforce  tnis  rule. 


C?.  which  parts  of  an  exrression  constitute  the  operands  to 
each  tneretion  within  that  expression  should  he  obvious  to 
the  reader.  There  w'ill  be  few  levels  of  operator  hierarchy 


nod  they  will  te  widely  recoeniteo.  ....F-  + 

Few  precedence  levels  ..........°+ 

ho  user-defined  rrecerierce  level?  T 

Operands  of  an  operation  are  obvious  T 


J73  defines  10  precedence  levels.  This  is  prcbatly  eore  than  the 
"few"  reauirec  by  C?.  however,  the  levels  are  traditional  an 0 familiar. 
(4  ."  > 


fi.  Fxrressions  of  a river  type  will  he  permitted  anywhere 
in  srurce  proarams  where  tort  constants  and  references  to 
variables  of  that  tyne  are  allowed.  ,...T 


(lection  4 ) 
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CA.  Constart  expressions  wi 
anywhere  constants  are  allowed, 
be  evaluated  h"fcre  run  tine. 


I l he  allowed  in  prop rans 

and  constant  expressions  will 


T 


tote:  J ?i  rrrscribes  constant  fcrsulss  which  contain  floatino  or 
character  operands  or  which  contain  the  exponentiation  operator.  (A.v) 


C 5 . T * e r e will  be  a consistent  set  o * rules  applicable  to 
all  parameters,  whether  they  he  for  procedures,  for  ty’.es, 
tor  exception  hand  l in::  r for  parallel  processes,  for 
declarations,  or  for  built-in  eforators.  There  will  Ho  no 
soecial  operations  fe.c.,  array  substructur irq ) applicable 
only  to  parameters.  Uniformity  an*  consistency  ccrtribute  to 
ease  of  learnino.  ....f 


Parameter  rules  consistent  i r,  all  contexts.  I 

t’o  special  operations  applicable  only  to  parameters  ............. p 


In  rrocedure  and  function  calls,  constants  and  simple  items  <*py  he 
passed  as  actual  parameters  oppreite  ♦ables  ( r ec ords / ar r ays  ) and  blocks, 
which  is  inconsistent  with  assignment  which  is  net  defined  for  either 
tables  or  blocks.  This  feature  is  used  to  defeat  type  checking  tor 
parameters  and  implements  a kind  of  "hidden"  union  as  formal  parameters 
and  allcws  the  writing  rf  user  neneric  rrocedums.  (?.?.3,  5 . 1 U > 

There  is  nc  impact  cn  t^e  existinr  Isnouaae  specification  to 
prohibit  the  r assise  of  such  r ara»'e*ers . The  impact  on  existing 
programs  is  unknrvn. 


C6.  Formal  and  actual  parameters  will  always  aoree  in  tyre. 

The  numDer  of  dimensions  hr  array  parameters  will  he 
determinable  at  compile  time.  The  si  ?e  and  subscript  ranae 
tor  array  naraireters  need  not  he  determinable  at  compile 
tire,  l ut  can  be  passed  as  part  r ♦ the  perimeter.  . . . . P 

Actual  and  formal  parameters  .ill  aoree  in  tv;  r 

P ank  of  parameter  arrays  is  fixer  et  rompile  time  T 

Par .'■•eter  array  si?e  end  subscript  ramje  can  te  passed  r 


i 


1 

i 


I 


se**  c 5 for  remarks  s'rut  formal  r. ?. remoter  tables  and  blocks.  S i 7 e 

and  sjbsrriot  rrnqe  of  parameter  arrays  are  fixed  by  the  formal 
parameter  description.  (.2.1.1,  3.10). 


■ 
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The  addition  ot  variable  si?e  formal  arrays  will  ado  moderate  cost 
to  tbe  parameter  passim  mechanism  but  should  have  ro  adverse  impact  on 
existin'  mechanisms  tor  passino  fixed  arrays. 


C7.  There  will  be  only  tour  classes  ot  formal  parameters. 
For  data  there  wi * l be  those  which  act  as  constants 
ref  resent i ng  the  actual  parameter  value  at  the  time  ot  call, 
and  those  which  rename  the  fctual  parameter  which  must  be  a 
variable.  In  adaiticn,  there  will  be  a formal  parameter 
class  tor  specifying  the  control  action  when  exception 


conditions  occjr  and  a class  tor  procedure  parameters.  . . . . P 

Act  as  const  tints  (call  by  value  rlus)  ...........................  f 

Act  as  variables  (call  by  reference)  . . . P 

Excertion  control  T 

Procedure  parameters  T 

(Act  as  varieties,  hut  call  bv  value)  ...T 

(Act  as  variables,  result  parameter)  ...I 


Call  bv  reference  porameters  are  restricted  to  arrays  and  blocks. 
Call  by  value  allows  assinnment  to  a formal  parameter  (which  ^oes  not 
alter  actual  parameter).  exception  control  is  by  label  parameters.  JM 
also  allows  "value  output"  parameters,  but  these  art*  restricted  to 
non-composite  tyres,  i.e.,  to  scalars,  sinnle  array  components,  or 
single  record  components.  (0.?.^,  3. ID) 

t.  eclassi  fyino  formal  parameters  requires  a significant  chance  to 
the  cvntax  of  the  lanouaoe;  parameters  are  currently  classified 
implicitly.  Doing  away  with  output  parameters  would  require 
complication  the  actual  parameter  descriptor  in  order  to  accommodate 
oassino  ot  record  and  array  comrnn*nts.  This  would  have  a moderately 
heavy  i mnac f . 


C'f.  Spec  i f i Co  t i or,  of  the  type,  ranqe,  precision,  dimension, 
scale,  and  format  of  oarameters  'ill  he  optional  in  the 
procedure  declaration.  None  of  t^e®  will  I e alterable  at  run 


time.  ....!■>♦ 

Af ova  iroperties  crtionnl  

Above  nrooerties  are  fixed  at  run  tire  ..F 


1 
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Generic  procedures  are  partially  achieve*  Me  through, 
formal  array  t ara^ctcrs  against  y i c h actual  'lara^Ptir'  rf 
tyre  "■•  y he  rB'S'c.  Thus,  the  irten4  of  r * is  achieved  at 
some  clumsiness  and  obfuscation.  F?.?.3,  T . 1 O') 


the  use 
v i r t u I l y 
t n r c s t 


of 
any 
3 4 


This  requirement  is  in  such  blatant  conflict  with  the  strict  tycir; 
conventions  dictated  by  Tinman,  that  ore  is  at  a loss  to  suggest  a 
scheme  for  meeting  C*'  that  is  not  a honeless  kludge.  In  fact,  the 
existing  J7.T  mecbanisT  is  no  worse  a kludge  than  any  other  ALGOL 
t>'r  'more  outtyce'). 


fS.  There  «w  i L l te  provision  4or  variaote  number*  of 
ar  -urents,  but  in  such  csr,'*s  all  ^ut  a constant  number  of 
the"  must  be  of  the  same  type.  whether  a routine  can  have  a 
variable  number  of  arguments  must  le  determinable  fro"’  its 
description  and  the  number  r*  srctm^nts  for  any  call  will  be 
determinable  at  compile  time.  . ...b 

variable  nur.c^r  of  arguments  possible  F 

All  tut  a ccrstant  nunl *r  of  argument*  have  the  same  tyre  F 

Number  of  arguments  in  each  call  is  fixed  <>t  compile  time  T 


The  nurb«r  of  arnt/Tents  is  fixed  for  all  urPr-def  ineu  and  built-in 
procedure*  an'*  functions.  It. 2. 3,  3.1ri) 

The  scctp  of  chance  to  nern.it  variable  length  argument  lists  is  not 
accommodated  aithin  *-t»  constructs  available  in  J 7 ' . S.ich 
implementation  approaches  as  sublists,,  for  example,  reouire  moderate  to 
heavy  changes  in  o?r?Teter  passing  cony»rtions  and  syntax.  The  simplest 
syntactic  approach  vcula  be  to  enclose  formal  sublist  orrmietf  rs  in 
parent! esc*  and  to  use  some-  variant  of  >-jhscrict  notation  to  select  the 
sublist  member,  all  rt  wficb  ren.ires  a 4 inner-  parameter,  accessible  to 
the  prorrem,  that  identifies  the  length  of  the  variable  j .irt  . 
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D1 . The  user  will  have  the  ohility  to  associate  constant 
values  of  any  tyre  with  identifiers.  ....T 


The  J73  DEFINE  permits  this,  as,  for  example: 

DEFINE  douelc,onf  "1.G"6?m. 


(? .5 . 1 ) 


D2.  The  lanruaae  will  provide  a syntax  and  a consistent 
interpretation  for  constants  of  built-in  data  tyres.  Numeric 
constants  will  have  the  same  value  (within  the  specified 


precision)  in  both  programs  and  data  (input  or  output).  . . . . P 

Literals  for  all  hui It-in  types  ................................. P 

Consistent  interpretation  in  prncram  and  data  ................... N /• 


J/i  provides  literals  for  all  non-structured  data,  but  provides  no 
array  literals  nor  record  literals.  (5.3) 

No  I/O  is  defined  in  J73.  (See  BIO.) 

It  would  be  of  modest  cost  to  add  structured  literals  to  J73.  The 
main  problem  will  be  to  find  sore  notation  that  doesn't  provoke  outrage 
from  some  corner  or  other. 


D7.  The  lanauage  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  part  of  their  declaration. 
Such  variables  will  be  initialized  at  the  time  of  their 
apnarent  allocation  (i.e.,  at  entry  tn  allocation  scope). 


There  will  be  no  default  initial  values.  ....p 

initial  value  can  be  specified  as  part  of  the  declaration  P 

Initialization  occurs  at  allocation  scope  entry ° 

No  default  initial  values  ....................................... T 


The  syntax  for  data  declarations  includes  the  facility  to  specify 
initial  values  for  so-called  "RFSERVF*'  data;  data  defined  as  allocated 
to  its  containing  scope  ("IN"  data)  may  not  he  initialized.  For  arrays, 
initial  values  may  te  specified  by  particular  subscript;  repetition 
counts  are  also  allowed.  Allocation  of  initialized  data  occurs  at 
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comoiif  titie,  i.e.,  it  is  globally  static  regardless  of  scene  of 
declaration.  P.1.S,  P.1.7) 

Initial  values  can  I®  trivially  provided  for  "P."  data.  It  n.ijIH 
sppt  tc  t ® deoraainn  of  efficiency  to  eliminate  the  alobal  static 
allocation,  although  providing  dynamic  initialization  at  see o®  entrance 
for  "FEKFKVE"  comes  free  if  it  is  done  for  "IK"  data. 


*4.  Tte  source  lan^uaye  ■*  t l l reuire  its  users  to  srccify 
individually  the  runne  of  all  numeric  variables  and  the  step 
size  for  fixed  point  variables.  The  range  specifications 
will  bp  interpreted  as  the  maximal  range  of  values  wnicn  will 
be  assigned  to  a variable  and  the  minimal  range  which  must  be 


sjnocrted  bv  the  obiect  code.  Range  ann  steo  size 
specifications  will  not  h»  internreted  as  defining  new 
types.  .r 

Numeric  variable  range  specification  mandatorv  ..V/* 

Fixed  point  variable  ster  size  specification  mandatory  ......... ,N /A 


Ran , e and  ster  size  specifications  do  not  define  a new  tyre  N/A 


j / » r.nt.s  provide  for  ram®  sue  c i f i c a t i on  at  all.  (Eecticn  P) 

There  would  be  moderate  cost  to  add  range  spe c i f i c a t i on  to  J7i 
(r.g.,  consider  borrowing  J -3  or  Fascal  notation).  Of  greater  cost  is 
the  aooition  of  range-checking  code  (Eee  P'j,  H9). 


D5.  The  ranqe  of  values  which  c.jo  be  associated  with  a 
variable,  array,  or  record  component,  will  be  any  built-in 


type,  »ny  defined  tyne,  or  a continuous  subsequence  nf  any 
enumeration  tvpe.  ....F 

ftenves  of  an  enumeration  type  are  allowed  A/t 

no  arbitrary  restriction*  on  the  structure  of  data  .......... . ...N/A 


Eee  P4 . ( Feet ion  2 ) 


r r, . 


The  l.',n"ul,ie  will  ornvirie  a orinter  necharism  which  can 
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he  used  to  build  data  with  shared  and/or  recursive 
substructure.  The  pointer  property  will  only  affect  the  use 
of  variables  (including  array  and  record  components)  of  some 
data  types.  Pointer  variatles  will  h®  as  safe  in  their  use 


as  are  any  ether  variables.  . . . . P- 

Kecursive  and  network  structures  provided  r- 

Handles  variable-value  and  structure-component  connections  P- 

Pointer  property  is  en  attribute  of  a tyoen  variable  ............ 

Pointer  property  not  frr  constants,  affects  only  assignment  .....F 

Pointer  property  mandatory  for  dynamic  allocation  .............. .N/ A 

Allocation  scope  never  wider  than  access  scope  f 

(Either  the  value  or  the  pointer  is  modifiable)  T 

(Pointer  ^ec  hani  sm  riar.dles  procedures  and  parameters)  P 

(Remap  and  replace  assignment  have  different  syntaxes)  ..........f 

(Built-in  dynamic  variable  creation)  ............................  I 

(Variable  equivalence  classes  are  ceclarable)  ..F 


J75  provides  for  poinfed-to  things  through  the  based 
variaulr  --  it*ms,  tables,  and  blocks  may  be  based.  References  to  based 
variables  occur  either  implicitly  through  an  "address"  variable  defined 
in  tne  declaration  or  explicitly  through  an  "address  :formula".  The 
address  variable  or  formula  is  notbina  more  than  an  integer  expression 
that  yields  a machine  address.  There  is  no  indelible  association 
between  a pointer  and  the  pointed-tr  object.  There  is,  therefore, 
virtually  ro  tyne-chec k i no,  and,  of  course,  even  machine  addressing 
exceptions  are  possible  *ith  no  heir  from  the  compiler  in  detecting 
these  anomalies. 

Shared  structures  (including  lists)  may  be  mechanized  by  declaring 
recoro  fields  wnich  Dy  convention  are  used  as  bases  or  pointers  to  other 
instances  of  the  record  tyre.  (There  are  other,  perhaps  more  common  and 
better  protected  ways  ct  implementin''  lists  in  which  a field  of  the 
record  (a  table  item  in  J73)  is  set  aside  as  an  index  to  another 
instance  — say,  th«*  next  in  the  list  --  of  the  record  tyre;  all  the 
space  is  taken  from  t statically  allocated  table  whose  definition  is  the 
record  prototvr.e.)  This  is  perhaps  best  seen  as  what  is  essertially  a 
machine-language  mechanization  o4  list  structures  (or  shared  records, 
networks,  etc.)  and  carries  with  it  the  same  level  of  error-propensity 
cr,  1 unintended  and/or  unwise  access  to  values  of  improper  type.  J73 
i(  not,  therefore,  offer  any  languaoe  constructs  that  make  clear  and 
ohvi  us  the  manipulation  of  shared  or  list-structured  values.  The  based 
•necranism  really  offers  a total  escape  from  tyre-checking  and  permits 
nearly  unrestricted  access  to  the  most  primitive  level  of  the  target 
machine  data. 

J/3  falls  s^nrt  of  meeting  the  D*  requirement  in  that  (a)  pointer 
variables  *?y  bp  totally  independent  of  the  pointed-to  object,  (b) 
pointers  may  assume  any  arbitrary  integer  value,  (c)  pointer  are  not 
restricted  to  a property  of  ? tyreo  variaolc,  and  (d)  the  allocation 
scope  can  be  wider  than  the  access  scope.  (Section  ?) 


r “ o u i r t m e n t DP 

rec?usp  this  renui  reir  e^t  i?  sc  broad  and  complex,  ana  because  the 
requirement  itself  is  pnt  *r*e  r>*  amt i quit i es  , it  is  not  clear  ho*  it 
would  impact  J?7  »frf  it?  provisions  depended  to  the  lannuaoe.  Somewhat 
super t i ci s l ly  addressed,  hv  sitIv  treatioc  the  based  property  as  an 
attribute  and  eliminating  address  formulas  anc  restrictirq  the  property 
tc  tables  alone,  tne  intent  of  is  could  be  met  at  modest  cost.  The 
affect  uf  this  one  existinc  rroorams  not  known. 


fr 
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FT.  T>e  u5?r  of  the  lanouaoe  will  be  ablp  tc  define  new  data 
types  and  operations  within  r^oarafs.  . . . .p- 


fvm  tlnucih  the  table  declaration  in  J73  is  ouite  flexiblr,  the 
inability  within  the  lancuaoe  to  define  records  as  types  or  to  define 
record?  containing  arrays  severly  limits  the  extensit i lity  desired  in 
fcl  . 

Operations  c.re  definatle  t*~rouoh  function?  and  procedures  only. 

The  larouays  does  not  permit  the  definition  of  new  infix  coer,>tors  or  to 
redefine  existing  infix  operators. 

S;-e  the  remarks  under  A?  for  data  definition  enhancements.  The 
addition  of  infix  operator  definitions  is  a "iror  effort  it  the  type  of 
operands  is  fixed  in  the  definition;  the  effort  becomes  greater  if 
ooeranu  node  is  used  to  select  the  proper  operator.  In  the  forner  case, 
the  existino  function  mechanism  within  the  compiler  serves  to  implement 
the  infix  operator  feature;  in  the  latter  case,  operator  selection 
becomes  somewhat  more  complex,  althouch  the  Tinman  proscription  against 
implicit  type  conversion  eases  th®  selection  problem. 

1 

F 2.  T^e  “use"  of  defined  tyres  will  be  i ndi  st  i ncjui  sh  afc  le 
from  built-in  types.  ' ....F 


since  definec  types  are  not  supported  in  J73,  this  reouirement  is 
not  met. 

Once  defined  types  are  allowed  at  all,  consistent  syntax  is  almost 
free.  The  real  effort  is  in  providinn  an  extension  to  allow  prototyoes, 
unions,  records  nf  arrays,  and  the  pointer  property  which  are  the 
essential  elements  missing  from  J73  to  allow  true  type  definition.  (See 
A 2 .) 


E3.  Each  program  component  will  be  defined  ir  the  base 
lanquane,  in  a library,  or  in  the  pronram.  There  vill  be  no 
default  declarations.  ,...P 


Some  attributes  of  type  definition  may  be  defaulted  in  J73:  integer 
size,  real  precision,  table  'ower  bounds,  character  strinc  size, 
parameter  t at  • I definition,  allocation  class  of  variables.  (Section  ?> 
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1*  » oj  l d he  6 mircr  charvie  to  require  complete  definition. 


E4.  The  user  .ill  he  atle,  withir  t'-e  source  languaoe,  to 
extend  existing  operators  to  rex  data  tyres.  ....F 


J f < -oes  not  sccrwndato  defined  ty-es  as  required  ly  Tinman. 


E5.  Type  definitions  in  the  source  lanouaae  will  rcr^it 
definition  ot  both  the  class  of  data  obiects  comprising  the 


type  and  the  set  of  operations  applicable  to  that  class.  t 
defined  tvr>e  will  not  automatically  inherit  the  operations  of 
the  aat a »ith  vhich  it  is  represented.  . ...t 

Construction  ...F 

Selection  f 

Predicates  ...,f 

Tyre  conversions  ..F 

Operations  and  data  can  be  defined  tmether  ......F 


Trie  requirement  of  05  is  entirely  t o r e i a n to  J 7 ^ . In  j ser.se,  of 
course,  anv  user-defined  procedure  may  define  a type  and  the  operations 
for  that  tvoe;  but  carryirio  this  notion  to  its  conclusion,  we  feel, 
violates  the  intent  of  Tinman  and  would  renner  the  language  comparison 
use  less. 


F 6 . The  oaf  a obiects  comprising  a defined  type  will  he 
definable  by  enumeration  ot  tleir  literal  names,  as  Cartesian 


products  cf  existing  types  (i.e.,  as  array  and  record 
classes),  oy  discriminated  union  (i.e.,  as  the  union  of 
disjoint  tyres)  and  as  the  power  set  of  an  enumeration  ty;e. 

These  definitions  vill  he  processed  entirely  at  compile 
time.  . . . .P- 

Fnumeratinn  ....P 

Cartesian  products  (records)  P 

Discriminated  union  F 

Powerset  nf  an  enumeration  ty^ c F 
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Status  tyoe  is  the  only  enumeration  mechanism  but  .Joes  not  define  a 
new  tyre  in  J/3;  it  is  treated  instead  as  (unsigned)  integer. 

Records  are  definable  by  the  table  mechanism,  tut  also  do  not 
define  tyes,  nor  may  tney  be  used  as  tyoe  constructors.  (Section  ?) 


fc  7 „ lyoe  definitions  ‘-v  4rae  union  (i.e.,  union  of 
non-di s j oi r t types)  and  subsettino  are  not  desired.  ....n- 


J?3  does  not  define  subs "tt i on,  tut  does  allow  tree  unions  throjgh 
specified  tables,  overlay,  and  haseo  variables.  (P.1.5.7,  1.5,  P.1.4, 
P.1.5,  P.I.o) 


18 . When  detinino  a type,  the  user  will  he  able  to  specify 
the  initialization  and  finalization  procedures  for  the  type 
and  the  actions  to  be  taken  at  the  time  of  allocation  and 


deallocation  nt  variables  of  that  type.  ....F 

Initialization  ..............F 

Finalization  ....................F 

Allocation  actions  F 

Deallocation  actions  F 


See  the  remarks  under  E5 
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FI.  The  lanouaoe  will  allow  the 
score  of  allocation  and  score  of 


user  to  distinguish  between 
access. 


Allocation  scone  is  never  narrower  then  access  scope.  "RfSFRVE" 
variables  are  in  effect  olobally  allocated,  but  access  is  strictly 
controlled  throuun  lexical  scone  rules.  Based  variables,  however,  may 
allow  an  exception  in  permitting  outer  scone  access  to  inner  scrpe  data 
structures.  (Section  ?) 


f ? . Tt-e  ability  to  limit  the  access  to  separately  defined 
structures  will  be  available  both  where  the  structure  is 
defined  and  where  it  is  used.  It  will  be  possible  to 
associate  new  local  names  with  separately  defined  nroarrm 


components.  ....F 

Allowable  operations  can  be  limited  F 

Access  can  be  limited  where  used  F 

Fxtern-l  declarations  neeo  not  all  have  the  same  scone  ....... ...F 

Naminn  conflicts  can  be  avoided  (renaming)  ...........F 


rata  types  are  not  definable  in  J73. 


F3.  The  scope  of  identifiers  will  be  wholly  determinen  at 
compiletime.  ....T 


The  score  rules  of  J73  conform  to  the  F3  description  (1.3.3,  ?.3) 


FA.  A variety  of  aor 1 icaticn-oriented  data  and  operations 
will  be  availabl®  in  libraries  and  easily  accessible  in  the 
language.  ....P 


Comment:  it  is  hard  to  understand  Ft  as  a language  requirement. 
The  requirement  should  he  that  "*ata  and  operations  should  be  definable 
by  means  of  a library  mechanism.  Mo  language  can  meet  the  abstract 
requirement  of  supportin';  unspecified  applications  in  its  libraries. 
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(J?3/I  for  WPAFH/AFAL  supports  a F OR  T R AN-  like  I/C  ca.iafc  i l i ty  . ) 


F5.  Proararo  components  not  defined  within  the  current 
prcorsti  and  not  in  the  base  larouaoe  will  be  maintained  in 
compile  time  accessible  libraries.  The  libraries  will  be 
carable  of  holding  anytninc  definable  in  the  language  and 
will  not  exclude  routines  whose  bodies  are  written  in  other 


source  languages.  ....p» 

nroorar  component  libraries  accessible  at  compile  time  .......... T 

libraries  can  contain  foreicn  lannuaae  routines  .................  P 

Interface  requirements  checkable  at  compile  time  ................ T 


Comment:  The  provision  in  F5  to  include  "foreion"  routines  in  the 
library  is  clearly  not  a lancuaqe  requirement  if  they  are  obliged  to 
exist  in  an  oDject  code  form  that  is  indi sti mini sh ac l e from  the  object 
rede  of  the  "Common  Hoi",  i.e.,  ir  what  sense,  then,  is  it  foreign?  Th<* 
requirement  appears  to  be  directed  at  thp  foreian  lanuuage,  not  to  the 
common  Hoi.  There  is  no  way  sensibly  to  evaluate  existing  languages 
against  this  part  of  the  requirement. 

j 75  for  WPATB/AFAl  accommodates  library  routines  written  in 
FORTRAN,  in  which  case  the  J77  obiect  code  is  oenerated  to  conform  to 
FORTRAN  conventions.  This  is  an  implementat ion  dependent  aspect  of  J73, 
althoorh  directives  arm  frovi^ed  to  guide  the  compiler  in  generating 
snecial-form  linkage  to  foreinn  languages. 


F 6 . Libraries  and  Comcools  will  be  i ndi st inquishable . They 
will  be  capable  of  holding  anything  definable  in  the 
language,  ana  it  will  be  rossible  to  associate  them  with  any 
level  of  programming  activity  from  systems  through  projects 
to  individual  proorams.  There  will  be  many  specialized 
corponls  or  libraries  any  user  specified  subset  of  which  is 


immediately  accessible  from  a given  proqram.  ....p 

Libraries  and  comnools  will  be  indistinguishable  r 

Immeaiately  accessible  sub  l ibrar ies  at  any  level  ................ P 


The  accessibility  of  sublibraries  is  more  a function  of  the 
oreratino  system's  data  manaoememt  characteristics  than  of  the  Hoi's 
library /rompool  urop**rt  i es  . 
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j 7 5 compoolr.  are  rrp  processed  data,  define,  and  subprogram 
de f ini t ions . Libraries  arc  not  defined  by  J?3,  but  in  practice,  their 
characteristics  are  taken  frcm  the  taraet  machine  operation  system 


conventions . 


7 . 6 . 4 ) 


F7.  The  source  lanoua.-e  w i 1 1 contain  standard  machine 
indcenoent  interfaces  to  n,1Chire  dependent  capabilities, 
inctudinn  oeri.iheral  equipment  and  special  hardware.  ....P- 


J f 7 provides  access  to  rcrtain  n act inp-der encent  characteristics  by 
T?ans  c*  inquiry  primitives  (See  13).  However,  no  mechanism  is  prnviied 
to  peripheral  ecuiprrent  as  special  hardware.  (1.?.?,  4.10.10.1) 

This  requirement  is  too  abstract  to  provide  meanincful  modification 
estimates. 
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r-1  . The  language  will  provide  structured  control  mechanisms 
tor  seruential,  conrti  t iona  l , iterative,  and  recursive 
control.  It  will  also  rmvide  control  structures  for 

(pseudo)  parallel  processing,  exception  handlinq,  and 

asynchronous  interrupt  hardline.  ....P 

Senuertial  execution  T 

Conditional  execution  T 

Iteration  T 

Recursion  -T 

(rsrudo)  parallel  processing  F 

Exception  hanrHirn  F 

Asynchronous  interrupt  hand l i nr  .........F 

Control  structures  from  a snail  set  of  simrle  primitives  ....... .F 


J73  provide*  GOTO,  IF,  and  F OF  statements.  Recursion  is  attainable 
u*ing  features  net  intended  to  support  recursion  ("based"  procedures  and 
toe  DEF  facility).  (3.2,  3. A) 

ijOTC  is  allowed  out  rf  scope,  ard  parameter  labels  are  permitted  as 
j 73 ' s solution  to  exception  exits  from  procedures.  This  conflicts  with 

02  . 


Parallel  crocessing  is  major  impact.  Exception  and  asynchronous 
interrupt  handling  could  be  imp l cnenred  through  the  library  somewhat 
trivially  it  certain  constraints  were  imposed  (such  as  pros c r iot ions 
against  global  exits  (GOTO)  from  exception  routines). 


G2.  Toe  source  language  will  provide  a "GO  TO"  operation 
applicable  to  program  labels  within  its  most  local  scope  of 


definition. 


J73  allows  direct  branches  cut 
(3.2,  3.4) 

'’ranches  out  of  scope  could  be 
nara,"’ter  labels  leaves  a small 
exits . 


F 

of  scope  and  parameter  label  GOTOs. 

trivially  proscribed.  Eliminating 
rap  in  providing  procedure  exception 


G3.  The  conditional  control  structures  will  be  fully 
partitioned  end  will  permit  selection  amono  alternative 
computations  based  on  the  value  of  a boolean  expression,  on 


JOVIAL  J73/1  27 

Hr  q.ji  r^nent  c.3 


t h r subtype  of  3 value  from  a di s c r imi nated  union,  or  on  a 


commuted  choice  ?mcro  labeled  alternatives.  . . . . h 

3ase^  on  Huolpsn  fmression  T 

Based  on  type  from  discriminated  union  F 

naspd  on  commuted  choice  amcno  labeled  alternatives  ............. T 

All  alternative  must  be  accounted  for  .....f 

simple  mechanisms  * i 1 1 he  supplied  for  common  cases  .............  F 


J7f  tines  not  provide  discriminated  unions.  J73  switch  supplies  the 
familiar  C«SF  facility.  Unaccounted  for  alternatives  are  undefined  in 
J 73  (in  the  SWITCH  statement  FIST  may  be  omitted  in  the  familiar  »ay). 

There  are  no  simple  mechanisms  for  common  cases.  (1.7,  1.*) 

I p j.  I ement  iny  discriminated  unions  must  precede  implmentinj 
computed  alternatives  based  on  union  type. 


GA.  Tna  iterative  control  structure  will  permit  the 
termination  condition  to  af orar  anywhere  in  the  loop,  will 
recuire  control  variables  to  he  local  to  th*  iterative 
control,  ,ill  allow  entry  only  at  the  head  cf  the  loop,  ana 
will  net  i moose  excessive  overhead  in  clarity  or  run  the 
execution  costs  for  common  special  case  termination 
conditions  (e.n.,  fixed  nurnner  of  iterations  or  elements  of 
an  .^rray  exhausted). 


Termination  can  occur  anywhere  in  the  loop ......P 

Multiple  terminatin'.:  precicates  are  possible  ................... .P 

Fntny  permitted  only  at  the  Icon  head  .......................... -H ♦ 

Simple  cases  are  clear  and  efficient  .....T 

Control  variable  is  local  to  the  loor  - F 

Control  value  is  efficiently  available  after  termination  ........F 


Termination  within  a loop  is  possible  by  GOTO,  WFTUKN,  STOP,  or  by 
turnino  tie  " VH I L T " condition  false.  (3.9.7) 

Multiple  termination  oredic »tes  are  only  possible  bv  normal 
conditional  branches  within  the  loop  that  force  exit. 

Tht  lannjaoe  permits  multiple  entry  loons  by  not  diannosino  them. 
However,  essentially,  J73  calls  a branch  irto  a loop  undefined  (1.9.2). 

Control  variables  may  be  any  non-connos i t e , scalar  variable. 
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ire  value  of  the  control  variable  after  normal  termination  is 
available  only  as  an  implementation  ouirk.  Since  ordinary  variables  are 
used  as  loop  control  variables  (3.9.1),  it  follows  that  on  abnormal  loop 
termination,  tne  variable  holds  its  last  assigned  value.  At  normal 
termination,  the  last  assigned  vslue  is  not  snecified,  i.e.,  the  user 
cannot  know  whether  inerremtarion  rrecedes  as  follow'  fhe  test.  (3.9) 

Restructuring  loops  is  a moderate  task  and  guite  localised. 
Compilers  should  he  obliged  to  diagnose  tranches  into  FOR-loo(s. 


G5.  Recursive  as  well  .is  nonrecursive  routines  will  he 
available  in  the  source  language.  It  will  not  be  possible  to 


define  procedures  within  the  body  of  a recursive 
procedure.  ,...n* 

No  recursive  procedures  within  recursive  procedures  T 

(Maximum  depth  of  recursion  can  be  specified)  ...................  F 

( Ri cur s ivem s s must  be  specified)  .........F 


Recursive  procedures  are  defined  hv  based  procedures,  PEF  PROC,  and 
wt F PR(l.  Since  full  J73  defines  recursive  procedures,  one  can  see  that 
th.®  recursive  cai  ability  ir>  level  I is  unintended.  (?.7) 


r>6.  The  source  larcmane  will  orovide  a parallel  processing 
capablity.  This  capability  should  include  the  ability  to 
create  and  terminate  (possible  rseudr)  parallel  processes  and 
for  these  processes  to  gain  exclusive  use  of  resources  during 


specified  portions  of  their  execution.  ....F 

Abl®  to  create  and  terminate  parallel  processes  ...F 

Process  can  gain  exclusive  use  of  resources  .....F 

no  parallel  routines  within  recursive  routines  .F 

o routines  within  parallel  routines  .....F 

v.»ifrum  number  of  simultaneous  instances  are  declarable  ,F 

(Access  rules  are  enforced)  F 


J 7?  makes  no  mention  of  parallel  processing. 

It  would  be  o very  heavy  itrtact  to  add  parallel  processing.  This 
reou i ronert  is  v'due  ard  potentially  defines  an  operation  system,  so  to 
evaluate  the  scale  of  the  effort  to  include  it  in  any  lanouaie  at  this 
Irvel  rf  investigation  i*  impossible. 
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r/.  The  exception  handlinq  control  structure  will  per nit  the 
user  cause  transfer  of  control  and  data  for  ary  error  or 


cnrertion  situation  which  rrioht  occur  in  a prooram. 

P r c n r a n,  can  uet  control  for  any  exception  r 

Parc^eters  can  he  passed  r 

Can  c,pr  nut  of  anv  level  of  a opgt  of  control  ........F 

fan  tandle  thr  exception  at  any  level  of  control  F 


J 7 does  not  address  exception  hardline.  In  practice,  there  is 
notHim  in  J 7'f  th.-t  prevents  exception  handling.  The  stylireo  system 
interface  is  handled  by  machine  lanpuaoe  but  J /7,-ca  1 1 ab  l e procedures. 
Jk>  i le  J f provides  no  exception  hanrllinn  artifices,  i me  l ment  at  i ons 
written  in  J 7 3 do  permit  rational  exception  h^ndlino. 

It  *culd  te  a rroderf.t-e  ly  heavy  irsict  to  add  exception  control 
constructs  and  discipline  to  Jf3. 


C-y . Ttnre  will  le  scurce  lannuaoe  features  whtich  permit 
delav  on  any  control  rath  until  some  srecitied  time  or 
situation  has  occurred,  which  permit  specification  of  the 
relative  priorities  amonn  oarallel  control  paths,  which  give 


access  to  reel  time  clocks,  whict  permit  asynchronous 
hardware  interrurts  to  be  treated  as  any  other  exception 
situation.  ....F 

Priority  specification  .F 

Synchronization  via  wait/enable  operations  .........f 

• ait  for  end  of  reil  time  interval  F 

wait  for  end  of  simulated  Mrre  interval  .....F 

Wait  for  hardware  ir.tcrrurt  .F 

(Can  enable  and  disable  interrupts)  ............................. F 
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Hi.  The  source  lanauaoe  will  he  free  format  with  an  explicit 
statement  delimiter,  will  allow  the  use  of  mnemoni ca  l ly 
significant  identifiers,  will  be  based  on  conventional  forms, 
will  have  a simple  uniform  and  easily  parsed  grammar,  will 
not  provide  unique  notations  for  special  cases,  will  not 
permit  albreviation  of  identifiers  or  key  words,  and  will  be 


syntactically  unambiguous.  ,...P» 

Free  format  with  statement  terminator .......T 

Mnemonic  identifiers  possible  ................................... T 

based  on  conventional  forms  T 

Sirple  grammar  . . b+ 

No  special  case  notations  ...................................... ,P* 

No  abbreviations  of  identifiers  or  keywords  ..............  F'* 

unarr.bi cunu s grammar  ...............................I 


Special  case  notations:  status  constants  (2.4.1).  Keywords 
abbreviated;  TRCtr,  tyre  specifiers  (e.g.,  F for  FLOATING,  s tor  INTEGER, 
etc . i . (2.3.1,  2.1) 


H2.  The  user  will  not  be  ablr  tc  modify  the  source  lanquaoe 
syntax.  Soec i f i ca  1 1 y , he  will  not  be  able  to  modify  operator 
hierarchies,  introduce  new  precedence  rules,  define  new  key 
word  forms  or  define  new  irfix  operator  precedences.  ,...T 


J73  does  net  allow  modifications  of  built-in  operations  in  any  way: 
precedence,  operator  meaninr,  and  lanouaee  words  are  irrevocably  fixed 
ov  the  J73  definition. 


H 3 . The  syntax  of  source  language  programs  will  be 
comrosable  from  a character  set  suitable  for  publication 
rc oses,  but  no  feature  of  the  language  will  be  inaccessible 
using  the  64  character  ASCII  subset.  ....T 


The  special  marks,  diuits,  and  liters  defined  for  J73  0.1)  are  a 
proper  ASCII  subset. 


I 

A 
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h 4 . He  language  Definition  will  provide  the  formation  rules 
for  identifiers  &nn  literals.  These  will  include  literals 
tor  numbers  an4  character  strin-s  and  a break  character  for 


use  internal  to  identifiers  and  literals.  ....P* 

freak  character  exists  .........T 

(Literals  are  * e l f-ident if yir o as  to  tyre)  ...................... p+ 

(Bit -string  l Here  Is  tor  ?nv  *vne)  ...T 


J > 5 uses  the  arc  strop  te  for  the  *reak  ch«,  rac  ter.  the  only  literal 
that  is  rot  s**  l f -de  f ini  r.q  is  the  unqualified  status  constant.  (1.*.1) 


h5.  Th«»re  will  be  nc  cent  inu*t  ion  of  lexical  units  across 
linos,  but  there  will  be  a way  to  include  obfect  chiracfers 
such  as.  end-of-line  in  literal  strin^-.  ....I 


Lines  ar**  undefined  in  J73;  the  incut  is  a continuous  stream  o f 
characters . 

It  would  he  i trivial  charge  to  the  language  to  satisfy  this 
rcqui rerent . 


M6.  key  words  will  he  reserved,  will  he  very  few  in  number, 
will  he  informative,  and  will  not  he  usable  in  contexts  where 
an  identifier  can  he  used.  ....! 


J75  defines  6b  keywords  which  are  reserved  (5.2.1).  15  of  these 
k*v*nr<s  are  unused  in  th**  Levrl  I 'i^set,  leaving  a net  of  53.  Ibis 
seems  tew  enough. 


H 7.  The  source  language  will  have  a single  uniform  comment 
convention.  comments  will  be  easily  distinguishable  from 
code,  will  be  introduced  bv  a single  (or  possibly  two) 
larouagr  defiled  characters,  will  permit  any  conLination  of 
characters  to  anp*ar,  will  oe  able  to  arpear  anywhere 
ref'tinablc  in  rnonrems,  will  automatically  terminate  at 
enrl-of-lire  if  not  otherwise  terminated,  and  will  rot 
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prohibit  automatic  refornattino  of  rr^orams.  ....Pt 

Uniform  comment  convention  1 

look  different  from  code  P 

Bracketeu  by  one  or  two  characters  .............................. T 

fan  contain  a^v  characters  T 

Can  aprear  anywhere  reasonable  T 

Terminated  by  the  end  of  the  line  f 

Compatible  witn  automatic  reformnttino  ..........................1 


Since  "any  characters"  may  appear  in  a comment,  comments  can  inoeeo 
lock  fuite  a bit  like  code.  (Tris  recuirement  seems  inconsistent). 

Comments  are  delimited  by  the  double  auote  mark  which  is  also  jseri 
to  delimit  define  Strinos  (5.4,  7 . *> . 1 ) . 


HP.  The  lanouaoe  will  net  rermit  unmatched  parentheses  of 
anvkini.  ....T 


There  will  he  a uniform  referent  notation.  ....F 


function  calls  use  round  trackets,  subscripts  use  sauare  brackets. 

The  replacement  of  souare  brackets  in  all  contexts  with  round 
brackets  introduces  a syntactic  ambiouity  between  replication  courts  for 
preset  table  data  and  the  subscript  notation  for  the  table  entry  to  be 
preset . For  example,  currently 

'•  TAHIE  A A C 1 ; 1 0 "»  F = (AA*?)(P); 

pc  '«  such  that  (AA*?)  is  a "number : formul a"  which  represents  a 
replication  count  (aa  must  be  a named  constant,  and  the  count  is  a 
comoilc-time  constant  expression).  Then,  the  prouram 

t«hlf  AAritimr  = r»A*?i  io); 

identifies  the  si  mole  entry  at  M*?  v M ft  is  to  be  preset  with  the 
initialized  value  zero.  The  former  case  presets  AA*?  entries  with  zero 
heoinrinc,  by  default,  with  the  first  entry).  by  this  example,  the 
rerlecem.ent  of  sauare  with  round  l rackets  demonstrates  the  ambiguous 
syntax.  / new  syntax  tor  initialized  data  would  solve  this  problem  at 
modest  cost. 


i 


i j 
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rtIT.  bo  lenauaje  defined  ivTbnl'-  apoearinq  in  the  same 
context  will  ‘■ave  esse  of  ia  1 1 v different  meaninos.  ....»’ 


JM  uses  the  = for  hoth  t*e  assirnrent  and  rcjuality  operators.  In 
add’ him,  the  r is  jspd  for  hoth  ha  red  variable  reference  and  fnr 
r»entrrblr  procedure  calls  fwhic*-  some  irioht  r ryue  is  consistent  --  a 
so-called  bused  procedure  is  one  whose  data  srace  is  supplied  by  tfe 
caller,  i.e.,  the  procedure  data  is  based  but  not  the  procedure  itself, 
which  is  the  reason  for  judo  inn  it  inconsistent  here).  In  addition, 
sjhscrir  t *'narle**-  are  used  for  ? variety  of  purposes  whose  syntactic 
context  ue  t e r mi  n«»  s the  mearino.  The  same  is  true  for  for  unqualified 
status  constants.  Lastly,  parentheses  are  used  to  delimit  constant 
expressions,  without  which  there  would  be  introduced  syntactic  a^tiouity 
in  initialized  data  constructions. 

The  lanoiiaqe  could  made  mere  consistent  at  probably  modest  cost, 
hut  e ary  *oulw  otiect  loudly  to  the  elimination  c-f  unqualified  status 
constants,  and  the  subscript  cases  merit  more  examination  than  is 
affordable  in  tMs  study.  Clearly  a new  assinnrpnt  operator  is  a 
trivial  charge,  a^ri  the  based  prrredure  call  ouesticr  is  arquable  in  any 
event . 


1 
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T 1 . There  will  b<»  no  defaults  in  (.roraus  which  affect  the 
orooran  locic.  That  is,  decisions  which  affect  urogram  Ionic 
will  te  fpaoe  either  irrevocably  when  ehe  languace  is  defined 
or  explicitly  in  each  prcaran. . 


J 25  defaults  the  ranre  and  precision  of  numeric  data.  however,  the 
la nguaifc  ooes  prov'irir  inouirv  primitives.  (2. 1.3. 2,  1.2.2) 

Similarly,  the  internal  representation,  character  sire,  and 
collation  stouence  for  the  character  type  are  iirp  lement  at  i on  dependent 
defaults  (which  the  programmer  may  not  override). 

tefault  range  aria  precision  is  trivially  eliminated.  The  character 
type  internal  representation,  collating  seruerce,  and  sire  defaults 
present  a more  difficult  problem. 


12.  Defaults  will  he  provided  for  special  capabilities 
affecting  only  object  representation  and  other  properties 
which  the  oroorammer  does  not  know  or  rare  about.  Such 
defaults  will  always  mean  that  the  oroorammer  does  not  care 


which  choice  is  mane.  The  programmer  will  he  able  to 
override  these  defaults  when  necessary.  ....P 

Defaults  specified  for  don't  care  cases  F 

Frcnramirer  can  override  the  defaults  .F 


The  nroorammfr  may  overrid®  size  and  precision  defaults,  but  not 
those  relation  to  the  character  type.  (See  II.) 


15.  The  user  will  te  able  tc  associate  compile  t i^e 
v-  riables  with  programs.  These  will  include  variables  which 
specify  the  obiect  computer  model  and  other  aspects  of  the 
otiect  machine  coof  iauration  . ....F’e 


J/.'  irevide?  a variety  of  target  machine  parameters  as  language 
primitives.  These  include  (1.2. 2) 


Pits  per  character 
i<  i t s rer  word 
Address  units  per  were 
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^jmier  cf  characters,  f er  (rj*ckec)  word 
“it  size  for  address  formulas 
Lowest  and  highest  addresses  of  statically 
allocated  data  srace 

In  addition,  the  laeauaoe  rrovides  inruiry  functions  for 

( 4 .1 D .1  d. . 1 ) size  of  allocate*  data  *cr  "baser"  procedures 
and  the  bit  size,  oyT  size,  and  word  size  of  data  strjctjres 
(items,  tables,  ‘■locks). 


14.  The  source  lannusoe  .ill  nermit  the  use  cf  conditional 
statements  (p.q.,  case  statements)  dependent  on  the  object 
environment  an*  other  c^mrile  tire  variables.  In  such  cases 
the  conditional  will  he  evaluated  at  compile  time  and  orly 
the  selected  rath  wit l he  compiled.  ....d- 


Ccr.di  tioria  l compilation  is  rossible  only  throuoh  the  use  of  special 
directives  ('SKIP,  'PFCIn,  !ENl).  The  conditionality  is  not  expressed 
throuoh  C*SF  or  IF-like  constructs. 

vnderate  to  heavy  cost  tc  imol^mert  compi l e -t ime  variables  and 
predicates,  depend i rq  of  course,  cn  the  sophistication  c>f  the  control 
constructs  (are  FCKs  allowed,  for  example'*) 


15.  The  source  lan.Juaae  will  eortain  * simple  clearly 
identi f i ?L  le  base  or  kernel  wbicb  houses  all  the  power  of  the 
lanruare.  To  the  extent  possible,  the  hpse  will  he  minimal 
• ith  each  feature  providin''  a sinale  unioue  capability  not 
otherwise  duplicated  in  the  base.  The  choice  of  the  base 
will  not  detract  from  the  efficiency,  safety,  or 

underst  andabi  l i ty  of  the  lanouane.  ....T 


j r?>  Level  J is  the  tssic  subsets.  (This  rec.ui  rement  sounds  like 
the  basis  for  extensibility,  in  ^hich  sense,  J73  partially  fails  exceot 
for  that  provided  throuoh  r r ncedimps / l ibrar i e s /c ompoc  Is  . ) 

j?7,  Level  T offers  few  redundancies  (IF  and  fwITCH,  'nr  example) 
and  these  are  useful. 
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16.  Lanouaqe  restriction?  which  are  dependent  only  on  the 
translator  end  ret  or  the  object  machine  will  be  specified 
exilicitly  in  the  larcuaoe  definition.  ....F 


J 75  leaves  compiler  capacities/limitaticns  as  almost  totally 
implementation  dependent. 

Setting  compiler  limits  witnin  the  lanqueqe  definition  may  have 
siqnificant  impact  on  existing  implementations  which  are  unknown  at  this 
writtinq. 


' 1/.  Lanouaoe  restrictions  which  are  inherently  dependent 
only  cn  the  object  environment  will  not  be  built  into  the 
lan-uane  definition  or  any  translator.  ....T 
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J1  . T I e lanyuanc  ana  its  translators  will  net  impose  run 
tire  costs  for  unneeded  rr  unused  generality.  They  will  be 
capable  of  producing  efficient  code  for  all  rroorairs. 


No  efficiency  rest  for  unused  features  .........P 

Ffficient  code  can  be  produced  for  all  features  ......P 


The  Ir.nouaot  in- lies  cert. in  costs  ter  little-used  or  unused 
features  /procedure  calls  tr  handle  based  rroceoures  and  p'-riTeter 
r rece  lures  T , although  the  lanunaoe  does  not  exclude  clever 
i'b  Indentations  t*at  may  cirrunvrrt  these  apparent  costs. 


J7.  Any  oct  i»r  izations  performed  by  t'e  translator  will  net 
change  the  effect  o * the  rrcnra^.  ....I 


insofar  as  it  is  provable  that  cccessive  t r ans  l at  io^s  of  th<» 
scurce  to  object  ervi  rcnrrenf  yield  an  epuivalent  program,  then  to  that 
deorec  optimization  will  not  chance  the  effect. 


J3.  The  source  language  will  nrovide  encapsulated  access  to 
machine  ascendent  hardware  facilities  including  machine 
lamuaoe  code  insertion*;.  . . . . P- 


J7*  ooes  not  surrort  machire  code  insertions,  but  there  is  nothing 
to  prevent  procedure  cells  to  programs  written  in  machine  language. 


J U . It  will  h»  possible  within  the  source  language  to 
specify  the  object  presentation  of  ro-pos i te  data  struct u res. 
These  descriptions  will  te  nrtional  bid  encapsulated  and  will 
be  distinct  from  the  lonicf.l  des  cr  i •>  t ion . The  user  will  be 
a ole  to  specify  the  M me /so ace  trade -of4  to  the  translator. 
If  not  specified,  the  ohicct  representation  will  be  optimal 


as  determined  ty  the  translator. 

Encapsulated  sieci f i c at  ion  of  renresentat ion  possible  ..I 

Snace/t  ine  tradeoff  can  be  specified  I’ 


\ 
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J 77  permits  the  proorammrr  to  allocate  the  components  of  a 
stricture  down  to  the  hit  level  through  the  use  of  specified  tables 
(?  .1 .5.7) . Allocation  can  he  controlled  to  machine  address  level  vith 
th<*  OVERLAY  statement  (1.^.1). 

•^ace-time  tradeoffs  are  srecifiert  through  tab  le /tat  le-i  tee  packin'] 
specifiers  to  yield  unpacked/f ?st-access,  somewhat-racked/tast-eccess, 
or  t i qht  l y-pa  c keri /s  lows  ccess  alternatives  <*?.1 .5.5.?)  . 


J5.  The  programmer  will  he  able  to  specify  whether  calls  on 
a routine  are  to  have  an  open  or  closed  implementation.  An 


open  and  a clored  routine  of  the  sine  description  will  hi<v» 
identical  semantics.  ....r» 

C ren/cl'' s ed  properties  can  he  specified  ....................... ..P  + 

Open  anc  closed  versions  have  the  name  semantics  ................ P 

J defines  only  closed  routines  as  procedures,  functions. 


However,  the  oarameterired  define  mechanisms  (P.5.1)  may  be  used  to 
obtain  the  •'oen  routine  effect. 
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Fxtrantcjs  Features 

» e reco’irend  that  the  folio  inn  features  ot  JOVIAL  J7?  (Level  I), 
not  required  by  the  Tinman,  he  kept: 

* character  striro  type  (assuming  that  the  Tin -an 
renuires  only  a character  type,  not  a character  strinn 
tvt.  e)  . 

* Result  parameters  (out; ut  r^ra-eters)  for  procedures. 

* Control  of  the  irternal  structure  of  records  throuoh 
(1)  sferi*yinn  the  internal  arrangement  of  the  recorc 
as  eitner  raralltl  or  serial  and  (?)  sperifyinn  the 
compiler  nackinn  aloorithm  to  re  used. 

* The  R F Dl'C  I F L E directive,  which  allows  optimization  of 
tjnetior  calls  which  cannot  he  done  without  the 
directive. 

* The  functions  * 0 S and  M C.N . 


the  following  features  provide  a usetul  capability.  They  should 
either  te  kept  intact  or  replaced  by  some  ecuivalert  feature: 

* Pit  strinn  tyre.  The  r*it  strinn  constant  appears  to 
be  overly  elaborate,  however. 

* The  SHIFT  function,  used  to  shift  hit  expressions. 

* The  hit-manipu lat inn  oferatcr*  NOT , AND,  OR,  *0R,  and 
ThV. 

» The  trace  directive.  This  dehiiyoino  aid  could  well  be 
e xp  andec . 


The  followim  features  are  machine  dependent,  hut  usetul.  They 
should  re  rptaineu  because  of  this  usefulness,  tut  it  should  t r required 
that  any  use  he  bracketco  ( enc?r su  l ated)  hy  statements  which  mark  them 
as  heir:  machinp  dependent  ( reoui r®ment  J*); 

* The  functions  ' IT,  pitcc,  t’Y T F , an*  char,  which  permit 
accessing  bits  and  bytes  of  expressions. 


The  followim  features  of  JOVIAL  J7*  (Level  1),  not  required  by  the 
Tinman,  should  be  deleted; 

* The  various  size  tunetion  (BITSI/f,  PYTF517F, 
W0KDSI7F),  which  return  tfe  number  of  strra  ie  units 
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allocated  to  various  entities.  This  is  too  hardware 
dependent . 

* Rased  data  and  procedures  and  the  related  features  of 

the  lanouaoe  (e.o.,  the  Pr>l7F  function  and  the 

interference  directive).  This  is  an  area  of 
nrouraffitino  entirely  foreian  to  the  Tinman  and,  until 
the  Tinman  addresses  the  subject,  these  features 
should  he  removed. 

* The  function  LOC,  which  returns  the  machine  address  of 
an  entity.  This  is  too  hardware  dependent  and  its 
prirarv  function  is  prubatly  that  of  a pointer. 

+ OVERLAY,  a form  of  free  union. 

* The  abilitv  to  return  through  more  than  one  level  of 
procedure  linkane  by  execution  a single  RFTl'RN 
statement,  while  perhaps  useful  in  some  cases,  this 
tends  to  obscure  prooram  flow  and  thereby  drive  un 
maintenance  costs. 

* Rlockino  of  data.  This  is  prcoerly  a function  of  a 
loader  or  link  editor. 
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A*;  a result  of  evaluatin'  J fT  r-:Pinst  the  Tinman  re;:ui  r ( me  nt  s , 
several  rood  features  if  the  lueouana  which  satisfy  or  cone  close  tr 
satisfying  these  rrcuirfTff'ts  have  hi  en  identified.  Thr  Umjjc.t 
rf  ,ji  r p s type  checkin  cf  all  entities  at  ccnfile  tire,  permits 
precision  specification  *or  individual  variables,  re.niires  t i * t the 

umber  of  dimensions,  type,  end  lower  subscrit  t hound  of  arrays  he  fixed 
at  cr  ■spile  time,  f err  its  re  let  ion  a l or  orators  * or  cnnmrirr  all 
primitive  data  tyres  including  enure  rat  inn  tyres,  allows  vsrixis 
built-in  aritniretic  operations  inclusion  interior  division  with 

rsmairder,  remits  explicit  conversion  between  various  data  tynes 
through  functions  such  as  lh'T,  FI^at,  CHAR,  and  MIT,  and  establishes  a 
few,  »asy  to  understand  roles  tor  expression  evaluation  are  operator 
nreced»rce.  ‘•ules  ter  handling  parameters  for  nroceoures  ano  built-in 
mentors  are  consistent  throughout  ♦■Fie  l ,r.  inane  definition.  T ti  e 
la-tiua  ie  provides  for  exception  control  parameters  (i.c.,  labels)  as 

well  as  procedures  as  parameters.  It  has  the  carahility  of  assiqninq 
identifiers  to  constants.  It  remits  i ni  t i a l i 7 a t i on  rt  "tost  date  types 
at  the  time  of  their  definition.  It  allows  the  definition  of  recursive 
procedures  and  recursive  data  structures  witF  the  use  of  a pointer 
mechanism.  The  larquaie  also  r ran  ires  that  all  itens,  arrays,  taules, 
etc.,  te  explicitly  declared  before  use,  hence  that  nr  implicit 

declarations  will  be  permitted.  The  scone  cf  these  identifiers  is  also 
deter" i rah  le  at  Compile  time.  Tre  user  can  have  access  to  both  comoools 
and  libraries.  The  syntax  rf  the  lannuare  is  consistent,  allows  Tree 
formattinn , and  does  not  rrrvioe  Tor  special  or  rare  cases.  The 

lanoufcr  syntax  carrot  he  modified  Fy  the  user  or  the  imrlerentor  in  any 
wav.  Sint:  l e Quotation  is  per  mitten  a?  a break  character  for  use  within 
names,  thus  allowing  tor  mnemonic  name*  to  te  used  as  icienti*i«rr  and  to 
increase  readability  of  nrceruns.  The  Innuaoe  has  68  keywords,  all 
reserve^.  J7J  assions  a unit  up  me, mine  to  most  symbols;  the  only 
exceptions  are  =,  which  is  u'pe  tr  do rote  both  assiorment  ard  lojicnl 
identity,  and  p,  which  is  used  T . r both  based  variabtr  reference  or  i for 
reentrant  procedure  calls,  t ^ imp ler enrat inn  riepennert  defaults  aro 
permitted  with  the  excretion  of  ranee,  precision  of  numeric  cats,  the 
internal  representation  of  character  tvpe,  and  the  collation  sequence. 
Th“  r roorammer  l as  the  facility  to  override  si7e  ard  precision  related 
defaults.  J7  3 provides  a variety  nf  tar  net  machine  related  Un  unit 
primitives.  br  user  can  specify  the  I its  rer  character,  bibs  per  « urd, 
njmber  of  characters  rer  necked  word,  lo.est  and  highest  addresses  of 
static  ria^a  stnrane,  etc.  The  Ine-'uape  i«  aesiured  around  3 lrv“l  1 
kernel  and  provides  for  extensibility.  It  also  nerrits  user  r.rfined 
open  and  closed  routines. 

There  are,  ♦owever,  many  c ha  r a c t e ri  st  i cs  in  which  JM  fills  sn.irt 
nf  the  I imran  renui recent s . I riif rv  amn nr  the'e  are  the  lack  of 
parallel  orncessinj,  exception  brortlino,  and  impUt /output  capabilities. 
There  is  no  facility  ir  tbe  lennuane  -ficb  car'  "rovii'p  alobal 
specification  of  rrecisinr  for  arithmetic,  ranee  nf  variables, 
enumeration  of  unordered  «ets,  and  truncation  nf  numt.ers  from  the  nqht 
instean  of  toe  left.  The  lannua-r  Joos  not  alio-'  definition  of 
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proceaures  with  a variable  number  of  arguments,  nor  does  it  define 
scalar  oorrations  for  arrays.  J 73  dors  not  allow  the  user  to  define  new 
data  tyfns  or  new  operators.  Compools  and  litraries  are  treateo 
differently.  The  cold  statement  is  unrestricted  ip  its  use  and  allows 
transfers  of  control  into  and  out  of  the  scone  i r>  which  it  appears.  Ihe 
lr>oo  control  variable  is  not  local  to  the  loon  and  has  to  Ke  defined 
before  use;  that  is,  outside  the  ra"Qe  of  tie  loop.  Tte  concept  of 
uni  for1"  referent  notation  is  ignored  ly  the  language;  the  syrtax  of 
function  calls  is  different  fro-  array  subscript  notation.  Moreover, 
the  functions  or  procedure  names  cannot  le  used  on  the  left  hand  side  of 
the  asri  'nn-ent  stat°inent  like  other  data  variables.  The  language 
itf  intinn  alto  *ails  to  specify  ""sewin'  independent  compiler 
l i mi t at  ions  . 

I .irou?'ie  designers  live  two  alternatives  in  modifying  J7/,  tc  meet 
t*-»  Tirwan  reou  i recent  s . Tl  « first  is  to  alter,  delete,  or  extend  ehe 
lanouaoe  c apat>i  l i t i e s , use  the  existing  syntax  and  semantics  as  the 
base,  and  arrive  at  the  desired  language.  ihe  second  is  to  draw  upon 
the  strengths  ol  J73  conceptually,  and  to  design  a new  language  from 
scratch  . 

The  first  alternative  will  reruire  the  aiciition  of  manv  features, 
such  as  taskim  capabilities,  exception  handling  by  means  of  control 
features  or  other  suitable  lecbanism,  a complete  input/outout 
cafability,  ability  to  define  new  data  tyres  and  operators,  including 
the  extension  of  new  operators  to  built-in  data  types.  Ixtensive 
modi f i cat  ion  of  the  pointer  capability  is  required,  because  of  the 
rudimentary  nature  of  the  current  mechanism.  In  particular,  cations 
should  be  rrovided  to  protect  the  areas  where  pointers  are  rointino 
during  dynamic  allocation.  dther  modi f i cat i ons  such  as  provision  for 
range  option  in  data  definition,  truncation  of  data  from  the  right 
instead  o*  the  le*t,  dynamic  as  well  as  static  allocation  of  arrays, 
variable  number  of  arguments  in  procedure  definitions,  etc.,  will  have 
to  be  j rovideo  for.  Certair  other  features  of  the  language,  such  as 
automatic  default  substitutions  for  intecier  size,  real  precision,  tible 
lower  bpurds,  etc.,  will  have  to  be  discarded.  The  overall  modification 
process  for  J73  will  be  nt  major  proportions,  but  it  can  be 
accomplished.  The  syntax  of  the  language  obtained  by  this  process  will 
certainly  be  clumsy  at  rlaces  since  it  contains  a blendim  of  the  old 
with  the  new. 

h e «.»e  l of  men  t and  definition  of  a new  language  to  meet  the  Tinman 
requirements  will  be  a maior  task  indeed,  but  it  has  a better  chance  of 
arriving  at  a language  which  is  consistent  and  elegant  in  its  syntax,  is 
modular  and  extensible,  as  is  capable  of  efficient  implementation,  many 
of  the  rood  and  useful  concepts  of  J75  c.’n  be  included  in  the  design  of 
such  a lanuuaue. 

Peuardless  rf  the  alternative  used,  the  rew  language  will  be 
significantly  different  from  the  existing  j /*  and  will  prof  ably  not 
allow  eyi«,tinn  J7'  programs  to  be  easily  modified  to  run  un*W  the  new 
version  of  the  language.  In  surh  a case,  there  seems  to  be  no  point  in 
claiminr  my  re  l a t ionsb  i ^ tetveer.  the  new  language  and  .173. 
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Introduction 

This  report  gives  a comparison  of  the  language  PEARL  to  the  Tinman 
language  requirements  (Department  of  Defense  requirements  for  High  Order 
Computer  Programming  Languages,  "Tinman"  - 1 Parch  1976,  section  IV). 
For  the  purposes  of  this  comparison,  PFARL  is  considered  to  be  defined 
by : 

pearl 

Subset  for  Avionic  Applications 
Lanquaae  Description 
June  1976 
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Tinman  contains  language  requirements.  This  report  compares 
PEARL  to  each  requirement  individually.  !f  a reouirement  is  totally 
satisfied,  the  accompanying  text  is  a summary  of  the  particular 
mechanism  used.  (Occasionally  no  text  is  needed  if  a requirement  is 
totally  satisfied.)  If  a reouirement  is  not  totally  satisfied,  the  text 
consists  of  a summary  of  the  shortcomings  and  such  items  as  the  scope  of 
the  changes  necessary  to  fully  meet  the  requirement  and  the  impact  of 
these  changes  on  existing  implementations. 

rach  Tinman  requirement  begins  with  an  introductory  paraaranh. 
These  paragraphs  are  reproduced  in  this  report.  In  many  cases  they  are 
followed  by  several  single-line  summaries  of  features  in  the  area  of  the 
requirement.  Usually  these  are  features  which  are  specifically  called 
for  in  the  requirement.  A feature  enclosed  in  parentheses,  however,  is 
one  which  the  reviewers  thought  possibly  desirable,  even  though  not 
called  for  in  the  requirement. 

Symbols  placed  beside  the  introductory  paraqraph  and  the  individual 
features  indicate  the  degree  to  which  the  requirement  or  feature  is 
satisfied  by  the  languaqe.  The  symbols  and  their  meanings  are: 

T - Totally  satisfied 

P - Partially  satisfied 

F - Fails  (not  satisfied  at  all) 

U - Unclear  from  the  documentation 

P+  - Almost  totally  satisfied 

P-  - Only  slightly  satisfied 

N/A  - hot  applicable  (used  only  for  individual 
features  when  the  requirement  is  not  satisfied 
af  all) 

(The  symbols  P,  P + , and  P-  will  often  be  used  with  requirements  which 
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nr**  stated  in  one  of  the  forms  "There  will  he  no..."  or  "All...",  **ven 
though  only  T or  F are  technically  applicable  in  these  cases.) 

The  report  concludes  with  two  summaries.  The  first  is  of  the 
features  of  PEANL  which  are  extraneous  to  Tinman  and  the  desirability  of 
retaining  each  of  them.  The  second  is  of  the  languaqe  as  a whole  and 
the  desirability  of  modifyino  it  to  brinn  in  into  line  with  thp  Tinman 
requ  i remerits . 
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A 1 . The  language  will  be  typed.  The  type  Cor  mode)  of  all 
variables,  components  of  composite  data  structures, 
expressions,  operations,  and  parameters  will  be  oeterminaole 
at  compile  time  and  unalterable  at  run  time.  The  lanquage 
will  require  that  the  type  of  each  variable  and  component  of 
composite  data  structures  be  explicitly  specified  in  the 
source  programs.  . . . . T 


PEARL  reauires  that  all  variable  data  must  be  defined  by  a data 
name  and  a data  type.  Constant  data  that  arc  to  be  associated  with 
identifiers  must  be  similarly  declared  and  must  also  contain  the 
invariable  (JNV)  attribute.  The  language  alsc  reauires  the  types  of 
arrays  end  each  element  cf  a data  structure  to  be  specified  by  the  user. 
Hence  the  language  meets  this  requi rement . Cro.  38-47) 

No  conflict  with  other  reciui  r ements  . 


A2 . The  lannuaoe  will  provide  data  types  for  integer,  real 
(flor.tino  point  and  fixed  point).  Boolean  and  character  and 
will  provide  arrays  (i.e.,  composite  data  structures  with 
indexable  components  of  homogeneous  type)  and  records  (i.e.. 


composite  data  structures  with  labeled  components  of 
heterogeneous  type)  as  type  generators.  ....P 

Integer  T 

Floating  Point  .................................. ................T 

Fixed  Point  F 

Boolean  .......p 

Character  String  T 

Arrays  T 

Records  P 


The  PEARL  larguaye  definition  permits  inteoer  data  type  (called 
FIXED),  -»nd  provides  for  floatino  point,  character  string,  array,  and 
structure  (record)  type,  althouoh  structures  cannot  contain  array 
components.  (Arrays  of  structures  are  permitted.)  There  is  no  fixed 
noint  type,  most  of  the  functions  of  Boolean  are  satisfied  by  bit  type 
of  length  one,  but  there  are  no  Boolean  constants. 

Adoition  of  the  missing  types  would  require  a modest  effort  in  most 
compilers.  For  fixed  point  the  hardest  problem  is  the  definition  of 
acceptable  scaling  rules.  The  aodition  of  structures  containina  arrays 
and  a Boolean  type  is  relatively  easy. 
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A3.  The  source  lanouaqe  will  require  nlobal  (to  a score) 
sper i f i cat  ion  of  the  precision  for  floatina  point  arithmetic 
an'-*  will  permit  precision  specification  for  individual 
variables.  This  soe c i f i cat  ion  will  be  interpreted  as  the 
msxirum  precision  required  by  the  program  locic  and  the 


minimum  precision  to  be  sunported  by  the  object  code.  ....P 

Global  arithmetic  precision  specification  mandatory  U 

Individual  variable  precision  spec i f i cat i on  permitted  ..P 


: 


Floating  point  variables  in  PEARL  can  be  oiven  a lenath  attribute 
(LENGTH),  which  specifies  the  number  of  bits  in  the  mantissa  of  the 
internal  floating  point  representation.  This  qives  something  of  an 
ability  to  specify  precision,  but  it  falls  short  tecause  there  is  no 
ac know lednemert  of  the  different  normalizations  extant  (binary,  octal, 
hexadecimal,  etc.).  One  assumes  that  this  specification  is  the  minimum 
number  of  bits  in  the  mantissa,  but  the  manual  has  no  explicit  statement 
tc  this  effect.  These  specifications  can  be  made  olobally  and 
individually,  but  the  manual  does  not  say  that  either  is  required. 

It  would  be  a simple  modification  to  the  language  to  require 
floatinn  point  precision  specifications,  and  only  a simple  modification 
to  compilers  if  they  are  to  be  interpreted  as  a directive  to  the 
compiler  when  it  chooses  between  various  precisions  at  its  disposal  on 
the  target  machine.  If,  however,  they  are  meant  to  have  some  impact  on 
the  encodino  of  comparisons  and  expression  evaluation  --  as  suoqesfed  bv 
the  Tinman  elsewhere  — then  the  cost  becomes  significantly  higher. 


A A . Fixed  point  numbers  will  be  treated  as  exact  quantities 
which  have  a range  and  a fractional  step  size  which  are 
determined  by  the  user  at  compile  time.  Scale  factor 


management  will  be  done  by  tne  compiler.  ....F 

Treated  as  exact  quantities  .....F 

Ranoe  and  step  size  determined  at  compile  time  ..................  F 

Scaling  handled  automatically  F 


Fixed  point,  in  the  Tinman  sense,  is  not  supported  at  all  by  PFARl. 

The  addition  of  fixed  print  requires  a moderate  effort  in  most 
compilers.  It  is  doubtful  that  treatino  fixed  point  data  as  exact 
quantities  is  practical,  however. 
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A5 . Character  sets  will  he  treated  as  any  other  enumeration 


type.  . . . . F 

New  sets  can  he  defined  as  enumeration  types  F 

ASCII  and  EBCDIC  are  provided  ................................... f 

(Conversion  capability  between  sets  is  available)  ...............  F 


The  lanauaoe  does  not  provide  the  user  the  capability  to  enumerate 
new  character  sets,  hence  it  does  not  provide  any  conversion  capability 
between  sets.  Conversion  routines  between  ASCII  and  EBCDIC  ar®  not 
reouired  in  the  lanouaae  definition,  and  if  present  in  the  library,  are 
an  accident  of  implementation.  The  language  defines  its  character  set 
to  consist  cf  £ 6 alphabetic  characters  (A-Z),  10  digits  (0  through  Q) 
and  15  special  characters.  Furthermore,  it  allows  installation 
dependent  special  characters  to  be  added  to  the  character  set.  (pp.  51) 

Tc  mot  this  requirement  the  language  must  provide  for  some  facility 
(e.g..  Status  Variables)  which  can  allow  a user  to  define  his  own 
character  set  for  a given  prooram.  The  library  must  support  the 
conversion  routines  to  convert  the  user  specified  character-set  into  the 
natural  set  for  the  machine  cn  which  the  compiler  is  implemented.  This 
should  include  routines  which  can  convert  ASCII  code  to  EBCDIC  and  vice 
versa. 


Implementation  of  this  facility  will  affect  all  existing  compilers. 
An  annrorriate  olace  in  the  prooram  will  have  to  be  established  to 
> define  new  character  sets.  All  processing  for  character  strings, 
literals,  etc.,  shall  have  to  be  modified  to  provide  for  tne  new 
character  set.  Several  conversion  routines  will  have  to  be  added  to  the 
l i brary . 


A 6 . The  lanouaae  will  require  user  specification  of  the 
number  of  dimensions,  the  range  cf  subscript  values  for  each 
dimension,  and  tyre  of  each  array  component.  The  number  of 
dimensions,  the  type  and  the  lower  subscript  bound  will  be 
determinable  at  compile  time.  The  upper  subscript  bound  will 


be  determinable  at  entry  to  the  array  allocation  scope.  ....P 

Number  of  dimensions  is  fixed  at  compile  time  ...................  T 

Type  is  fixed  at  compile  time  ................................... T 

Lower  subscript  bound  is  fixed  at  compile  time  ...T 

Upper  subscript  bound  is  fixed  at  scope  entry  ................. ..F 

Subscripts  only  integers  or  from  an  enumeration  type  p 

Subscripts  will  be  from  a continuous  range  ......T 
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The  user  is  required  to  specify  the  number  of  dimensions  of  the 
■array  at  compile  time  ar  well  as  the  type  and  the  upper  bound  of  the 
subscript.  The  lower  subscript  tound  is  fixed  at  1.  The  user-provided 
upper  subscript  bound  must  be  an  integer  constant.  Subscripts  are 
inteqers  only. 

To  fully  meet  this  requirement  the  capabilities  of  fixing  unoer 
subscript  bounds  at  scope  entry  rather  that  compile  time  and  using 
elements  of  an  enumeration  type  as  subscripts  must  be  added  to  the 
lanauane.  Poth  of  these  would  have  only  a moderate  cost,  with  the  cost 
of  the  latter  being  ? part  of  the  cost  of  aridinq  enumeration  types  in 
general. 


A 7.  The  language  will  permit  records  to  have  alternative 
structures,  each  of  which  is  fixed  at  compile  time.  The  name 
and  tyre  of  each  record  component  will  be  specified  by  the 


user  at  compile  time.  ....F 

Alternative  structures  for  records  are  possible  F 

Discrimination  condition  may  be  any  Boolean  expression  ..........F 


Alternative  structures  are  not  supported  by  PEARL  at  all. 

The  addition  of  such  a capability  typically  has  a heavy  impact  on 
the  syntax  of  any  language,  but  beyond  this  the  costs  (e.g.,  to  the 
storage  allocator  and  code  generator)  are  only  moderate. 


1 
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B 1 . Assignment  and  reference  operation  will  be  automatically 
defined  for  all  data  types  which  do  not  manage  their  data 
storage.  The  assianment  operation  will  permit  any  value  of  a 
given  type  to  be  assigned  to  a variable,  array,  or  record 
component  of  that  type  or  of  a union  type  containing  that 


type.  Reference  will  retrieve  the  last  assigned  value.  ....R 

Automatically  defined  for  any  type  (except...)  p 

Available  for  individual  components  .............................  T 

(Assignment  and  reference  via  functions)  V 


The  language  defines  the  assignment  and  reference  operations  for 
numeric,  bit,  character,  duration,  clock,  etc-,  types  of  data.  These 
operations  are  also  defined  for  elements  of  arrays  and  structures,  out 
not  for  conformable  arrays  or  structures.  Functions  can  only  be 
referenced,  not  assigned.  (p.  71 -72) 

To  extend  assignment  to  conformable  arrays  and  structures  would 
reauire  a minimal  effort.  Allowing  assignment  to  functions  would 
reouire  substantially  more  work. 


R2.  The  source  lanquage  will  have  a built-in  operation  which 
can  be  used  to  compare  any  two  data  objects  (regardless  of 
type)  for  identity.  ...,P+ 


The  equality  operator,  ==,  is  provided  in  the  language  for  logical 
comparison  of  numeric,  character,  bit,  or  time  type  of  data. 
Comparisons  of  arrays  or  records  (structures)  is  not  defined.  A 
comoarison  results  in  a bit  (not  necessarily  realized)  beino  set  or 
cleared;  the  value  is  set  to  'P'B  if  the  relationship  is  false  (not 
equal).  (p.  66) 

The  addition  of  array  and  record  comparison  requires  a minimal 
effort . 


P3.  Relational  operations  will  he  automatically  defined  for 


numeric  data  and  all  types  defined  by  enumeration.  ....P 

Ruilt-in  for  all  numeric  and  enumeration  types  ....f* 

Ordering  can  be  inhibited  when  desired  .......................... f 
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PEARL  provides  for  rQ,  NE,  LT,  CT,  LE  and  6E  relational  operators 
for  comparison  of  numeric  data  types.  However,  enumerated  data  types 
are  not  supported  at  alt.  (r-  6t-6 7) 

To  meet  this  requirement  the  language  must  provide  for  status 
variables  and  extend  the  definition  of  all  relational  operators  to  the 
enumerated  data  types.  mechanisms  should  be  provided  in  the  lanouaqe  to 
inhibit  relational  operations  wherever  unordered  sets  are  intendeo. 

Implementation  of  these  modifications  will  affect  all  existing 
compilers  of  the  language.  The  syntax  analysis,  expression  processino, 
and  logical  expression  processino  portions  of  the  compiler  will  be 
affectea  to  a moderate  extent. 


B4.  The  built-in  arithmetic  operations  will  include: 
addition,  subtraction,  multiplication,  division  (with  a real 
result),  exponentiation,  inteoer  division  (with  integer  or 
fixed  point  arciuments  and  remainder),  and  negation.  ....M 

Addition  ..T 

Sul  traction  T 

Multiplication  T 

Division  with  real  result  ..T 

Exponentiation  .......T 

Integer  and  fixed  point  division  with  remainder  ......F 

Negation  ..........T 


all  the  operations  specified  in  this  requirement  are  included  in 
the  language  with  the  exception  of  inteqer  division  with  remainder, 
(pp.  6U-61) 


a new  operator  for  integer  division  with  remainder  needs  to  be 
defined  end  included  in  the  lanouage.  minimal  changes  will  be  required 
in  the  languaoe  syntax  and  expression  processino  routines  to  implement 
this  feature. 


95.  Arithmetic  and  assignment  operations  on  data  which  are 
within  the  range  specifications  of  the  program  will  never 
truncate  the  most  significant  digits  of  a numeric  quantity. 
Truncation  and  rounding  will  always  be  on  the  least 
significant  digits  and  will  never  be  implicit  for  inteqers 
and  fixed  point  numbers.  Implicit  rounding  beyond  the 
specified  precision  will  he  allowed  for  floatino  point 


PEARL  7 

Requirement  R5 


numbers. 

>.'eve  r from  the  left  for  data  within  ranqe  ...................... .11 

Never  on  the  riaht  for  inteqer  and  fixed  point  .U 

Implicit  floatina  point  roundina  beyond  precision  allowed  U 

(Kun  time  checks  car  be  avoided)  u 


The  lanauaqe  does  not  specify  rules  for  truncation.  It  is  possible 
to  declare  the  lenatb,  in  bits,  of  integer  quantities,  so  it  appears 
that  truncation  on  the  left  is  possible.  Since  no  language  definea 
constructs  are  Drovided  for  ranqe  or  precision  specification,  no  rules 
are  specified  for  roundino  bevond  user  scecified  precision.  All  details 
of  truncation  and  rounding  are  implementation  dependent. 

To  meet  this  requirement  the  lanquane  will  first  have  to  provide 
for  KANfiF  and  PRECISION  specification.  Then  language  will  have  to 
specify  rules  that  truncation  should  take  place  only  from  the  right. 
For  intermediate  computations,  rounding  for  floating  point  numbers 
should  take  place  beyond  the  precision  specified  by  the  user. 

Implementation  of  these  features  in  the  language  syntax  and 
expression  processing  routines  will  require  moderate  chances. 


B<S.  The  built-in  Boolean  operations  will  include  "and", 
"or",  "not",  and  "xor".  The  operations  "and"  and  "or"  on 


scalars  will  be  evaluated  in  short  circuit  mode.  ....»’ 

Short-circuit  and  p 

Short-circuit  or  n 

Not  T 

Xor  f 


The  language  provides  for  AND,  OR  and  NOT  Boolean  operators  but 
does  not  provide  for  XOR.  The  language  also  does  not  explicitly  specify 
that  the  evaluation  of  expressions  containing  AND  and  OP  should  he  done 
in  short  circuit  mode,  nor  does  it  forbid  it.  Hence  the  evaluation  of 
these  operations  is  implementation  dependent.  <r.  f>5) 

The  Boolean  operations  should  include  an  XOR  operator.  The 
definition  of  the  AND  arc4  OR  operations  should  explicitly  emphasize  that 
short  circuit  mode  is  required.  Some  of  the  existing  compilers  which 
are  not  currently  utilizing  short  circuit  evaluation  will  have  to  be 
modified  slightly. 


"" 


r 
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R ? . The  sourer  language  will  nernit  scalar  operations  and 
assignment  on  conformable  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  logical 


structure.  . . . . f 

Scalar  operations  on  arrays  ................. ............F 

Assignment  between  records  and  arrays  of  conformable  type  .......F 


The  PFARL  language  definition  does  not  allow  arrays  and  structures 
to  be  referenced  as  a whole  (pp.  42,45)  except  as  procedure  parameters 
and  at  initialization.  This  implies  that  scalar  operations  (e.q.,  ♦ , -, 
*,  /)  cannot  be  oerformed  on  arrays  as  a whole  and  must  be  restricted  to 
t^eir  individual  elements.  A similar  interpretation  forbids  assinnment 
operation  to  be  performed  between  conformable  arrays  or  records  as  a 
whole  . 

To  meet  this  requirement  the  lanouaae  must  extend  the  definition  of 
scalar  operations  and  assignment  to  conformable  arrays  and  structures  as 
a whole.  This  may  require  restriction  of  numeric  operators  to  only  the 
numeric  fields.  It  may  also  require  special  definitions  for  * and  / 
oreratrrs  for  multidimensional  arrays  (e.q.,  the  * operation  tor 
two-dimensional  arrays  should  be  different  from  matrix  multiplication). 

Implementation  of  extended  definitions  of  these  operators  will 
require  minimal  effort  in  the  existino  compilers. 


88.  There  will  be  no  implicit  type  conversions  but  no 
conversion  operation  will  be  required  when  the  type  of  an 
actual  parameter  is  a constituent  of  a union  type  which  is 
the  formal  parameter.  The  language  will  provide  explicit 
conversion  operations  amoro  integer,  fixed  point  and  floatino 
point  data,  between  the  object  representation  of  numbers  and 
their  representations  as  characters,  and  between  fixed  point 


scale  factors.  ....P 

ho  implicit  conversions  F 

Fxplicit  between  integer,  fixed  point,  and  floatino  point  T 

Fxplicit  between  fixed  point  scale  factors  .F 

(Fxplicit  between  interer  and  Boolean)  .......................... T 

(Fxplicit  between  inteoer  and  enumerated  types)  ...F 

(Fxolicit  between  different  enumerate*  types)  F 


The  lanquaoe  allows  implicit  conversions  during  assignment 
operations  if  the  mode  of  the  expression  on  the  right  is  different  from 
the  mode  of  the  symbol  on  the  left.  These  conversions  include  automatic 
conversions  from  floating  to  fixed  (inteoer),  floating  to  bit,  and 
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art  justments  for  variables  of  different  bit  and  character  lenoths 
<pp.  71-72).  operators  for  explicit  conversions  (e.g.,  FLOAT,  Fix, 
CHAR,  FIT,  FIT)  are  also  provided  (p.  69).  Fixed  point  is  not  supported 
at  all. 

The  language  definition  should  forbid  all  implicit  conversions, 
includino  the  ones  for  assignment  statement.  Built-in  operators  should 
he  provided  in  the  lanruaae  for  conversion  between  fixed  point  scale 
factors  at  the  time  a fixed-point  capability  is  added.  These 
modifications  to  the  language  definition  and  the  existing  compilers  will 
require  a minimal  amount  of  effort. 


B9 . Explicit  conversion  operations  will  not  be  reaui red 
between  numerical  ranoes.  There  will  be  a run  time  exception 


condition  when  any  inteaer  or  fixed  point  value  is 
truncated.  ....F 

Implicit  conversion  between  ranoes  N/a 

Exception  condition  on  integer  and  fixed  point  truncation  .......F 


Since  the  lanouaqe  does  not  permit  user  specification  of  ranges, 
the  ouestion  of  conversion  between  ranges  does  not  arise.  The  languaqe 
also  docs  not  require  that  an  exception  condition  be  raised  when  an 
integer  or  fixed  point  quantity  is  truncated  during  computations.  These 
aspects  are  implementation  dependent  by  the  language  definition. 

To  meet  this  requirement  the  lanquage  definition  has  to  permit  user 
specification  of  ranges.  Then  it  should  allow  automatic  conversion 
between  these  numerical  ranges.  The  language  definition  should  also 
require  a run  time  exception  condition  to  be  raised  if  an  integer  or 
fixed  noint  value  is  truncated. 

minimal  changes  to  the  lanauaae  syntax  and  existing  implementations 
will  be  required  to  implement  these  modifications.  The  code  generator, 
the  syntax  checker  and  the  expression  processing  routine  will  be 
affected. 


R1U.  The  base  lanquaqe  will  provide  operations  allowing 
programs  to  interact  with  files,  channels,  or  devices, 
including  terminals.  These  operations  will  permit  sending 
and  receiving  both  data  and  control  information,  will  enable 
orograms  to  dynamically  assian  and  reassign  I/O  devices,  will 
provide  user  control  for  exception  conditions,  and  will  not 
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be  installation  depencert.  ...-T 

Sending  and  receiving  of  data  T 

Sending  and  receiving  of  control  information  ..............T 

Dynamic  device  assignment  T 

User  exception  condition  control  .1 

Installation  independence  ..................................T 

(Data  formatting  capability)  .................................... T 

(Reading  and  writing  of  bit  strings)  ............................ T 


The  PEARL  language  provides  excellent  1/0  facilities.  These 
facilities  have  to  te  specified  by  the  user  in  the  system  fivisioo  and 
the  problem  division.  In  the  svstem  division  the  user  specifies  the 
standard  peripherals,  the  process  peripherals,  the  sensors,  effectors, 
interrupts,  sionels,  and  the  device  connections.  Accessing  and 
transmitting  of  data,  opening  and  clrsino  of  files,  using  INTERRUPT, 
PND-OF-FILE,  and  SIGNAL-TDFNTI FIFP  handling,  etc.,  are  done  in  the 
problem  division.  These  two  divisions  combined  allow  the  user  to  ooen 
or  close  tiles  (using  OPEN  and  CLOSE),  declare  devices  (e.o.,  DCL 
(SWITCH,  LAMP)  DEVICE  SINK  BIT(I)  GLOBAL;)  and  interrupts  (e.g.,  DCL  I f) 
INTERRUPT  GLOBAL;),  connect  T/0  channels  to  devices,  create,  delete, 
access,  and  protect  files  (using  SIGNAL-IDENTIFIERS),  send  or  receive 
data  directly  from  devices  (e.q.,  TAKE,  SEND  etc),  format  and  deformat 
data,  and  monitor  graphic  I/O.  The  user  has  the  ability  to  connect  any 
channel  to  any  device,  thus  makino  his  program  largely  installation 
independent . Only  portions  of  the  system  division  need  to  he  changed 
when  a computer  or  installation  is  changed.  (pp.  100-131) 

No  conflict  with  other  retirements . 


: 


: 


311.  The  language  will  provide  operations  on  data  types 
defined  as  power  sets  of  enumeration  types  (see  E6).  These 
ooerations  will  include  union,  intersection,  difference. 


complement,  and  an  element  predicate.  ....F 

Union  ........F 

Intersection  ....F 

Difference  ..........F 

Complement  ....F 

Membership  predicate  F 

(Set  inclusion)  F 


The  PEARL  language  docs  not  support  any  user-defined  data  types  and 
hence  does  not  permit  the  powerset  operations  listed  ip  this 
reoui remert . 


i 
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Cl  . 


Side  e 


amonr  the 
lef t-to-rin 


fleets  whi 
arcument s 
ht. 


eh  are  dependent  cn  the 
of  an  expression  wi 


evaluation  order 
ll  be  evaluated 


F 


Side  effects  must  occur  in  le ft-to-rioht  order  f 

(Embedded  assirnments)  F 


The  lanquaqe  manual  makes  no  statement  about  the  order  of 
evaluation  of  operands. 

Function  references  are  the  only  PEARL  item  capable  of  having  side 
effects.  To  impose  a lef t-to-r ioht  order  of  function  evaluation  is 
usually  a minor  problem  in  any  compiler. 


C 2 . Which  parts  of  an  expression  constitute  the  operands  to 
each  operation  within  that  expression  should  be  obvious  to 
the  reader.  There  will  be  few  levels  of  operator  hierarchy 


and  they  will  be  widely  recognized.  ,...T 

Few  precedence  levels  T 

No  user-defined  precedence  levels  T 

Operands  of  an  operation  are  obvious  ........................... .T 


The  lanquaoe  establishes  precedence  levels  for  binary  and  unary 
operators  (pp.  60-69)  for  expression  evaluation.  It  establishes  certain 
well-understood  rules  for  interpretation  of  expressions.  The  user  does 
not  have  the  authority  to  alter  or  define  his  own  precedence  levels  for 
these  operators.  The  lanquaqe  definition  clearly  defines  the  operands 
for  each  of  the  operations.  Hence  the  lanquaqe  fully  meets  this 
requi remert . 

No  conflict  with  other  requirement*;. 


1 


I 


C 3 . 

Expressions  of  a 
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to  be 


both  constants 
substituted  in 


. . . . T 


and  variables 
their  Place. 
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fco  conflict  with  other  requirements. 


C4.  Constant  expressions  will  be  allowed  in  programs 
anywhere  constants  are  allowed,  and  constant  expressions  will 
be  evaluated  before  run  time.  ....F 


The  syntactic  definition  of  F-E  A RL  forbids  use  of  constant 
expressions  in  Diace  of  constants,  especially  in  declarations  and 
specifications  (po.  43,  54,  55,  etc.).  Only  INT E6E R-CONSTANT  is  allowed 
to  be  used  while  declarina  a fixed  point,  floatino  point,  bit,  or 
character  type  variable;  not  any  type  of  expression. 

The  lanquaqe  definition  should  be  made  flexible  to  accommodate 
constant  expressions  in  place  of  constants  in  declarations  «nd 
specif i cat  ions . 

The  necessary  chanaes  in  the  syntax  are  trivial  but  it  could  De 
Tioderatelv  expensive  to  implement  in  any  compilers  which  do  not  already 
have  at  least  a rudimentary  form  of  this  capability. 


05.  There  will  he  a consistent  set  of  rules  applicable  to 
all  parameters,  whether  they  be  for  procedures,  for  types, 
for  exception  handling,  tor  parallel  processes,  for 
declarations,  or  for  built-in  operators.  There  will  he  no 
special  operations  (e.q.,  array  substructur inq)  applicable 
only  tc  parameters.  Uniformity  and  consistency  contribute  to 
ease  of  learninq.  ....T 

Parameter  rules  consistent  in  all  contexts  ...........T 

No  special  operations  applicable  only  to  parameters  ....T 


pearl  satisfies  this  requirement  fully.  However,  only  procedures 
use  parameters  in  PEARL,  so  the  requirement  is  almost  satisfied 
vacuously.  The  properties  of  parameters  for  subroutines  (call 
procedures)  and  functions  (function  procedures)  are  identical, 
(pp.  91-97) 


C6 


Formal  and  actual  parameters  will  always  agree  in  type 
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The  number  of  dimensions  for  array  parameters  will  be 
determinable  at  compile  time.  The  size  and  subscript  range 
for  array  parameters  need  not  be  determinable  at  compile 


time,  but  can  be  passed  as  part  of  the  parameter.  ....P* 

Actual  and  formal  parameters  will  aqree  in  type  ................. T 

Rank  of  parameter  arrays  is  fixed  at  compile  time  ............... T 

Parameter  array  size  and  subscript  ranoe  can  be  passed  ...F 


The  actual  and  formal  parameters  must  aqree  in  number  and  type.  If 
the  actual  parameter  is  an  array,  the  correspondi nq  formal  array  rust 
have  the  same  number  of  subscripts  and  elements.  Hence  dynamic  arrays 
are  ruled  cut  in  the  lanouaoe  definition  as  parameters  and  the  size  and 
subscript  ranoe  cannot  be  passed  as  a parameter  for  dynamic  arrays 
<r.  9?). 

To  meet  the  Tinman  requirements  the  lanquaoe  must  provide  dynamic 
arrays.  This  will  permit  passina  array  size  and  subscript  ranges  as 
parameters  in  proredure  calls.  Implementation  of  this  feature  will 
reauire  a moderate  amount  of  effort  and  will  affect  the  parameter 
checking  mechanisms,  code  generation,  run-time  storage  allocation  for 
arrays,  etc.,  in  existinq  compilers. 


C 7 . There  will  be  only  four  classes  of  formal  parameters. 
For  data  there  will  be  those  which  act  as  constants 
representing  the  actual  parameter  value  at  the  time  of  call, 
and  those  which  rename  the  actual  parameter  which  must  be  a 
variable.  In  addition,  there  will  ce  a formal  parameter 
class  for  specifying  the  control  action  when  exception 


conditions  occur  and  a class  for  procedure  parameters.  ....P 

Act  as  constants  (call  hy  value  plus)  ..T 

Act  as  variables  (call  by  reference)  T 

Fxception  control  F 

Procedure  parameters  F 

(Act  as  variables,  but  call  by  value)  ........................... T 

(Act  as  variables,  result  parameter)  f 


Transfer  of  information  between  actual  and  formal  parameters  can  be 
performed  in  two  ways:  (1)  call  by  value  and  (?)  call  by  reference.  In 
the  first  case  thp  1NV  attribute  may  be  specified  for  the  formal 
parameter,  which  causes  it  to  behave  as  a constant  on  each  reference. 
Exception  handling  parameters  (e.g.,  labels)  are  not  permitted  in  the 
lanquaqe  definition,  nor  is  a user  allowed  to  pass  a procedure  name  as  a 
parameter.  Hence  the  lanauane  only  partially  meets  this  requirement, 
(pc.  93-94) 
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T »•  e lannuage  definition  i 1 1 have  to  be  extended  to  permit 
exception  control  parameters  (e.n.,  labels)  to  be  included  in  the  actual 
and  formal  parameters.  It  shtuld  permit  other  procedures  to  be  included 
as  parameters  as  well.  Rules  for  procedures  to  be  passed  as  oarameters 
will  hive  to  be  established  (e.p.,  recursive  calls,  levels  o*  recursion, 
entry  mints,  etc.). 


CP.  Spec i f i cat  ion  of  the  type,  range,  precision,  dimension, 
scale,  and  format  of  parameters  will  be  optional  in  the 
procedure  declaration.  None  of  them  will  be  alterable  at  run 


ti"“*.  . . . . F 

Above  properties  optional  F 

Above  properties  are  fixed  at  run  timo  .......................... F 


C * the  listed  properties,  PEARL  parameters  have  only  typ", 
dimension,  and  format.  All  such  properties  are  fixed  at  compile  time. 

The  lanouage  definition  will  have  to  be  modified  to  allow  for  the 
range,  precision,  and  scale  specification  of  variables  and  parameters  at 
the  user's  option.  The  ability  to  include  the  array  dimension  and 
format  in  the  formal  parameter  should  also  be  included.  All  cf  these 
properties  must  be  aeterminable  at  run-time. 

Implementation  of  these  modifications  to  the  language  definition 
will  require  moderate  effort  to  chanoe  the  existing  compilers.  These 
changes  will  affect  the  syntax  analyzers  and  the  code  oenerators. 


C9 . There  wilt  be  provision  for  variable  numbers  of 
arguments,  but  in  such  cases  all  but  a constant  number  of 
them  must  be  of  the  same  type,  whether  a routine  can  have  a 
variable  number  of  arguments  must  be  determinable  from  its 
description  and  the  number  of  arguments  for  any  call  will  be 


determinable  at  compile  time.  ....F 

Variable  number  of  arguments  nossible  F 

All  but  a constant  number  cf  arguments  have  the  same  type  F 

Number  of  arouments  in  each  call  is  fixed  at  compile  time  .......l 


The  lannuaqe  does  not  permit  user-defined  procedures  to  have  a 
variable  number  of  arguments. 
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both 


The  addition  of  such  a capability  would  require  e moderate  effort, 
in  modifications  to  the  lanouaye  itself  and  to  existing  compilers. 


r 
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01.  The  user  hill  have  the  ability  to  associate  constant 
values  of  any  tyne  with  identifiers.  ....T 


Variables,  array  names  and  structure  names  can  be  used  to  represent 
constart  values,  end  can  be  protected  aqainst  modification  by  the 
attribute  INV  (p.  47).  An  entity  containinq  the  INV  attribute  in  its 
declaration  must  also  have  the  1NIT  attribute  unless  the  entity  is  a 
formal  parameter. 

ho  conflict  with  other  requirements. 


02.  The  lanouape  will  provide  a syrtax  and  a consistent 
i nteroretati on  for  constants  of  built-in  data  types.  Numeric 
constants  will  have  the  same  value  (within  the  specified 


precision)  in  both  programs  ard  data  (input  or  output).  ....P- 

Literals  for  all  built-in  types  ................................. T 

Consistent  interpretation  in  program  and  data  U 


The  languaoe  provides  detinitions  and  syntax  for  inteqer,  floatinn 
point,  bit  string,  character  strino,  clock,  and  duration  type  literals. 
The  lancuaae  manual  makes  no  explicit  statement  about  consistency  of 
interpretation  between  program  constants  and  data.  Therefore  all  the 
dangers  alluded  to  in  this  reauirement  are  present.  (pp.  32-37,  127) 

It  is  trivial  to  change  the  manual  to  require  consistency  of 
interpretation  but,  as  the  Tinman  infers,  this  can  cause  amazingly 
expensive  problems  in  compilers. 


03.  The  lannuaoe  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  part  of  their  declaration. 
Such  variables  will  be  initialized  at  the  time  of  their 
apparent  allocation  (i.e.,  at  entry  to  allocation  scope). 


There  will  be  no  default  initial  values.  ....p+ 

Initial  value  can  be  specified  as  part  of  the  declaration  .......T 

Initialization  occurs  at  allocation  scope  entry  ................. T 

No  default  initial  values  ..P- 


Variables,  arrays  and  structures  can  be  qiven  initial  values  when 
they  are  declared  by  using  the  INIT  attribute  followed  by  an  expression. 
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The  value  of  the  expression  must  be  of  the  same  mode  as  the  data  items 
beino  given  the  initial  value.  The  values  of  variables  occurring  in  the 
expression  must  he  known  when  the  initialling  declaration  is  made. 
This  implies  that  initialization  can  occur  at  allocation  scope  entry 
time. 

In  the  cases  of  arrays  and  structures,  if  there  are  more  data 
elements  than  values,  then  the  surplus  elements  are  initialized,  by 
default,  to  the  value  of  the  last  entry  in  the  list  (p.  46).  No  default 
initialization  of  other  variables  is  specified  in  the  manual.  The 
manual  emphasizes  that  the  user  must  assign  some  value  (either  by 
assignment  or  initialization)  to  variables  before  using  them  (p.  41). 

The  default  initialization  of  array  and  structure  elements  in  cases 
where  the  data  elements  exceed  the  initial  values  ir  number  should  be 
forbidden.  The  user  must  be  made  responsible  for  ini ti a l i zat ion  or 
assionment  of  values  to  variables  before  using  them. 

Trivial  changes  to  the  lanquaae  definition  and  existing 
implementations  will  be  required  to  meet  this  requirement. 


D4 . The  source  language  will  require  its  users  to  specify 
individually  the  range  of  all  numeric  variables  and  the  step 
size  tor  fixed  point  variables.  The  range  specifications 
will  be  interpreted  as  the  maximal  range  of  values  which  will 
be  assigned  to  a variable  and  the  minimal  range  which  must  be 
supported  by  the  object  code.  Range  and  step  size 
specifications  will  not  be  interpreted  as  defining  new 


types . . . . . F 

Numeric  variable  range  specification  mandatory  .................. F 

Fixed  point  variable  step  size  specification  mandatory  F 

Range  and  step  size  specifications  do  not  define  a new  type  N/A 


The  lanauage  definition  does  not  require  nor  permit  explicit  user 
specification  of  ranges  for  numeric  variables,  nor  does  it  provide  a 
facility  for  step  size  specification  for  fixed  point  numbers.  The 
lanauaue  completely  fails  to  meet  this  requirement. 

To  meet  this  requirement  PEARL  will  have  to  modify  the  language 
definition  to  allow  user  specification  of  the  range  of  variables  at  the 
time  of  declarations.  It  must  also  require  step  size  specification  for 
fixed  point  numbers. 

toderate  chrnqes  to  existino  implementations  are  required  to 
accommodate  these  lar.quage  modi  tications  - 
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DS.  The  range  of  values  which  can  be  associated  with  a 
variable,  array,  or  record  component,  will  be  any  built-in 
tyre,  any  defined  type,  or  a contiauous  subseouence  of  any 


enumeration  type.  ....F 

Panels  of  an  enumeration  type  are  allowed  ...F 

No  arbitrary  restrictions  on  the  structure  cl  data  ....f 


PEARL  does  not  meet  the  first  part  of  the  requirement  because  it 
does  not  permit  user  specification  of  ranges.  It  does  not  meet  the 
second  part  of  the  requirement  either  since  it  does  not  allow  arrays  to 
De  part  of  structures  and  vice  versa. 

Tc  meet  this  requirement  the  lanquaoe  must  permit  the  range  of 
values  which  can  be  associated  with  a variable,  array,  or  structure  to 
be  any  built-in  or  user  defined  type.  Furthermore,  the  user  should  be 
able  to  make  arrays  a part  of  structures  and  vice  versa. 

All  existing  implementations  will  have  a major  impact  to 
incorporate  these  language  modifications.  The  ranges  and  the  use 
defineo  data  types  have  to  be  included.  Then  necessary  modifications 
have  to  be  made  in  the  structure  declarations,  array  declarations, 
syntax  analyzer,  storage  allocation,  and  code  generation  portions  of  the 
compiler  to  incorporate  these  features. 


06.  The  lanouage  will  provide  a pointer  mechanism  which  can 
be  used  to  build  data  with  shared  and/or  recursive 
substructure.  The  pointer  property  will  only  affect  the  use 
of  variables  (includinc  array  and  record  components)  of  some 
data  types.  Pointer  variables  will  be  as  safe  in  their  use 


as  are  any  other  variables.  ....F 

Recursive  and  network  structures  provided  ...F 

Handles  variable-value  and  structure-component  connections  ......F 

Pointer  property  is  an  attribute  of  a typed  variable  ............ F 

Pointer  property  not  for  constants,  affects  only  assignment  F 

Pointer  property  mandatory  for  dynamic  allocation  .F 

Allocation  scooe  never  wider  than  access  scope  f 

(Either  the  value  or  the  pointer  is  modifiable)  ..I 

(Pointer  mechanism  handles  procedures  and  parameters)  F 

(Remap  and  replace  assignment  have  different  syntaxes)  ...... ....F 

(Built-in  dynamic  variable  creation)  ............................ F 

(Variable  equivalence  classes  are  declarable)  ....F 
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pparl  has  no  pointer  mechanism  at  all.  Hence,  the  lanauage  fails 

I to  meet  this  requirement  completely. 

The  language  definition  will  have  to  he  modified  to  include  a 
oointer  mechanism  which  is  capable  of  beinq  associated  with  each  type  of 
variaDle,  can  be  modified  and  permits  modification  of  the  variable  or 
structure  pointed  to,  is  capable  of  being  assigned  to,  and  which  does 
not  permit  access  from  outside  the  scope  of  its  allocation. 

Implementation  of  these  language  features  will  reouire  a moderate 
to  heavy  effort  on  existing  compilers  in  the  areas  of  data  typ»s, 
storage  allocation,  assignment  statement  orocessing,  data  definition, 
I etc . 


A 
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El.  The  user  o*  the  lanquage  will  be  able  to  define  new  data 
tyres  and  operations  within  programs.  ....F 


Kc  facilities  are  available  in  PEARL  to  allow  the  user  to  define 
new  data  types  or  new  operations. 

vonif ication  to  language  definition  and  syntax  is  required  to  allow 
user  definition  of  new  data  types  and  operations.  These  operations  can 
oe  in  the  form  of  procedures,  but  the  lanquage  must  provide  the  type 
checking  facilities  to  these  defined  operations  and  data  types. 

Pajor  modifications  to  existing  compilers  will  be  required 
encompassing  the  lexical  and  syntax  analysis  routines,  the  expression 
processing  routines,  and  the  tyre  checkino  routines,  to  implement  these 
language  features. 


F?.  The  "use"  of  defined  types  will  he  indistinguishable 
from  built-in  types.  ....F 


The  language  does  not  provide  for  user-defined  data  types  and  hence 
does  not  meet  this  requirement. 

The  syntax  of  user  defined  data  type  and  operations  as  well  as 
their  usage  should  be  treated  the  same  way  as  built-in  data  types  and 
operations  are  treated  in  the  lanouaqe.  This  will  allow  uniformity 
throuohout  the  language  and  permit  the  difference  between  the  built-in 
types  and  defined  types  to  grow  dim  in  the  eyes  of  the  users. 

All  existing  compilers  for  the  lanquage  will  be  affected  to  provide 
for  this  uniformity  of  built-in  and  defined  types.  These  features  will 
require  minimal  effort  assuming  thev  are  implemented  with  those  required 
to  implement  requirement  Et. 


E3.  Fach  program  component  will  be  defined  in  the  base 
lannuaae,  in  a library,  or  in  the  program.  There  will  be  no 
default  declarations.  ....P* 


The  lanquage  requires  that  all  variables,  arrays,  structures,  I/O 
facilities  (e.g.,  devices,  channels,  etc.)  be  declared  in  the  proqram  or 
procedures  before  use.  For  global  definition  the  language  also  requires 
these  entities  to  be  specified  in  the  procedures  in  which  they  are  being 
used  after  having  been  declared  in  the  main  proaram. 
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Although  definitions  may  occur  in  all  areas  of  a program  (i.e., 
nodule,  task,  procedure,  and  block),  certain  definitions  are  only 
permitted  in  certain  areas  (p.  3P).  For  instance,  a task,  procedure, 
device,  *ile,  semaphore,  interrupt,  or  signal  definition  can  only  occur 
in  a mooule,  while  a BEGIN  blcck  can  only  te  defined  in  a task, 
procedure,  or  another  BEGIN  block. 

There  are  a small  number  of  ore-defined  mathematical  functions  for 
which  no  specification  is  necessary. 

Tc  require  that  the  pre-defined  Functions  be  specified  before  Jse 
is  a trivial  problem,  if  that  is  truly  wanted. 


E A . The  user  will  be  able,  within  the  source  languaqe,  to 
extend  existing  operators  to  new  data  types.  ....F 


Because  definition  of  new  types  is  impossible,  this  facility  is 
currently  not  available  in  the  lanouaqe. 

while  defining  the  facilities  of  user-defined  data  tyoes  and 
operations  (see  requirement  El),  the  lanquaoe  definition  should  also 
permit  the  use  of  existing  built-in  operators  with  user-defined  data. 

Assuming  that  this  facility  will  be  implemented  in  conjunction  with 
the  facilities  specified  in  requirement  El,  a moderate  effort  will  be 
t reouired  to  include  it  in  existino  compilers. 


E5.  Tyoe  definitions  in  the  source  language  will  permit 
definition  of  both  the  class  of  data  objects  comprising  the 
type  and  the  set  of  operations  applicable  to  that  class.  A 
defined  type  will  not  automatically  inherit  the  operations  of 


the  data  with  which  it  is  represented.  ....F 

Construction  - ...........F 

Selection  F 

Predicates  ................F 

Type  conversions  F 

operations  and  data  can  bp  defined  together  ...F 


The  language  does  not  have  any  facility  for  definino  new  data 
tyoes  . 
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As  part  of  the  facility  for  defining  new  data  types  and  operations 
specified  in  requirement  El,  the  language  definition  should  also  require 
that  the  user  specify  the  operations  permissible  cn  those  data.  The 
defined  tynes  should  not  automatically  inherit  the  operations  of  their 
constituent  Duilt-in  types.  The  definable  operations  will  include 
constructors,  selectors,  predicates  and  type  conversions. 

A moderate  effort  will  be  required  to  implement  this  feature,  alonn 
^ith  those  called  for  in  reouiremenf  FI,  in  the  existing  compilers. 


F6.  The  data  objects  comprisina  a defined  type  will  be 
definable  by  enumeration  of  their  literal  names,  as  Cartesian 
products  of  existino  types  (i.e.,  as  array  and  record 
classes),  by  discriminated  union  (i.e.,  as  the  union  of 
disjoint  types)  and  as  the  power  set  of  an  enumeration  type. 
These  definitions  will  he  processed  entirely  at  comoile 


tire.  . . . . r 

bnumeration  F 

Cartesian  products  (records)  F 

Discriminated  union  F 

Powerset  of  an  enumeration  type  F 


None  of  these  mechanisms  can  currently  be  used  for  defining  user 
defined  types. 

The  lanquage  definition  should  be  modified  to  include  data 
definition  through  enumeration,  Cartesian  products,  discriminated  union, 
and  powersets.  Implementation  of  these  mechanisms  in  the  existino 
camoilers  will  require  moderate  effort. 


E 7.  Type  definitions  by  free  union  (i.e.,  union  of 

non-disjoint  types)  and  subsetting  are  not  desired.  ....T 

PFAPL  permits  no  form  of  free  union,  including  CVFRLAY. 


C8.  When  definino  a type,  the  user  will  be  able  to  specify 
the  initialization  and  finalization  procedures  for  the  type 


w 
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and  the  actions  to  be  taken  at  the  time  of  allocation  and 
deallocation  of  variables  of  that  type.  ....F 

Initialization F 

Finalization  ..................................F 

Allocation  actions  ............F 

Deallocation  actions  F 


The  current  definition  of  the  lanquaqe  does  not  meet  this 
reouirerent,  because  it  has  no  facility  for  defininq  ret*  data  types. 

while  defininq  the  new  data  types  the  lannuage  should  provide  for 
ini t i a l i zation  of  these  data,  and  user  specification  of  actions  to  be 
taken  for  allocation,  deallocation  and  at  termination. 

moderate  effort  will  be  required  to  implement  these  facilities  at 
the  same  time  as  those  called  for  in  requirements  El,  E4  and  F5. 
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FI.  The  lanouaqe  will  allow  the  user  to  distinguish 
scope  of  allocation  and  scone  of  access. 


between 


▼he  language  defines  clobal,  local,  and  block  allocation  scopes  for 
variables,  arrays  and  structures.  The  system  division  allows  the  user 
another  means  for  specifyina  allocation  scopes  tor  process  signals  and 
peripherals.  The  access  scope  tor  these  variables  is  either  equal  to  or 
less  than  their  allocation  scope.  For  example,  if  a variable  is  defined 
hnrh  «t  the  global  and  local  level,  the  local  definition  prevails  and 
the  alobal  variable  becomes  inaccessible  in  that  scope.  Since  the 
language  ooes  not  allow  pointers,  it  is  not  possible  from  an  outer  scone 
to  access  variables  which  were  allocated  in  an  inner  scope.  Hence  the 
language  meets  this  requirement. 

No  conflict  with  other  requirements. 


F <? . The  ability  to  limit  the  access  to  separately  defined 
structures  will  be  available  both  where  the  structure  is 
defined  and  where  it  is  used.  It  will  be  possible  to 
associate  new  local  names  with  separately  defined  Drogram 


components. 

Allowable  operations  can  be  limited  ............................. F 

Access  can  be  limited  where  used  f 

External  declarations  need  not  all  have  the  same  scope  F 

Naming  conflicts  can  be  avoided  (renaming)  T 


fince  the  lanquage  does  not  allow  user  definition  of  new  data 
types,  it  does  not  support  the  first,  part  of  this  requirement.  However, 
the  renaming  capability  is  implemented  in  the  language  throuoh  the  IDENT 
attribute.  Thus  the  language  only  partially  meets  this  requirement. 

The  language  must  be  modified  to  support  user  definition  of  new 
data  types,  and  it  must  restrict  the  operations  permissible  on  these 
types  so  that  changes  to  the  defined  types  do  not  alter  the  meanino  nr 
effect  of  the  calling  program. 

This  modification  to  the  compiler  will  reauire  minimal  effort  when 
implemented  along  with  the  features  celled  for  in  requirements  FA  and 
ES. 


FT. 


The  scope  of  identifiers  will  be  wholly  determined  at 
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compile  time. 


. . . • T 


l^c  lanquape  permits  four  levels  of  scope:  System,  global,  local, 
and  block  (pp.  -2,  7b,  ini).  These  must  be  specified  by  the  user  at 
compile  time.  Fach  identifier  will  have  only  one  definition  in  each 
scope . 

Wo  conflict  with  other  requirements. 


FA.  A variety  of  application-oriented  data  and  operations 
will  he  available  in  libraries  and  easily  accessible  in  the 
larruaoe.  . ...T 


The  lanquaoe  supports  the  notion  of  libraries  rather  uriouely.  It 
permits  specification  of  liorary  names  fcr  variables,  arrays, 
procedures,  and  other  entities  through  the  GLORAL-QUAL I F Itk  option 
(po.  52,  Kft).  It  also  reouires  that  compiler  libraries  be  provided  to 
contain  certain  standard  functions  <pp.  92).  other  routines  related  to 
applications  can  also  be  stored  usina  any  one  of  these  options. 

No  conflict  with  other  requirements . 


F 5 . Program  components  not  defined  within  the  current 
proorair  and  not  in  the  base  languane  will  be  maintained  in 
compile  time  accessible  libraries.  The  libraries  will  be 
capable  of  holdinq  anything  definable  in  the  language  and 
will  net  exclude  routines  whose  bodies  are  written  in  other 


source  languages.  ....P 

Program  component  libraries  accessible  at  compile  time  ..........T 

Libraries  can  contain  foreign  languaqe  routines  F 

Interface  requirements  checkable  at  compile  time  T 


The  languaqe  allows  proaram  libraries  to  be  available  at  compile 
time.  These  libraries  are  capable  of  holdinq  various  entities  that  are 
definable  in  the  languaqe  (e.q.,  data,  variables,  procedures,  and 
tasks).  However,  the  language  manual  does  not  defire  interface  with 
routines  compiled  from  other  lanquaqes,  including  assembly  languaqe 
routines. 
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The  interfaces  with  procedures  written  in  languages  other  than 
PEARL  should  be  defined.  This  may  require  processing  of  header 
information  in  the  compiled  routines. 

A minimal  effort  will  be  required  to  incorporate  these  features  in 
existing  compilers  which  check  the  interfaces  already,  but  to  add  such  a 
capability  to  an  existing  compiler  could  be  quite  expensive. 


Ff  . Libraries  and  Compcols  will  be  indi  st  inouishab  le  . They 
will  be  capable  of  holdino  anything  definable  in  the 
larquaqe,  and  it  will  be  possible  to  associate  them  with  any 
level  of  programming  activity  from  systems  through  projects 
to  individual  programs.  There  will  be  many  specialized 
coirpools  or  libraries  any  user  specified  subset  of  which  is 


immediately  accessible  from  a given  nrooram.  ....T 

libraries  and  compoels  will  be  indistinguishable  ........T 

Immediately  accessible  sub  l i brari  er.  at  any  level  T 


Since  the  GLCBAL-QUALIF IER  allows  any  data  definition,  including 
procedures,  tasks,  and  data  items,  to  be  stored  in  the  library,  it 
arrears  to  perform  the  functions  of  both  compools  and  libraries. 
Furthermore,  selecting  suitable  names  for  sub-libraries  and  storing 
project  oriented  entities  in  them  car  heir  create  project  related 
libraries. 

No  conflict  with  other  reoui rements . 


f7.  The  source  language  will  contain  standard  machine 
independent  interfaces  to  machine  dependent  capabilities, 
including  peripheral  equipment  and  special  hardware.  ....! 


The  language  provides  facilities  for  interfacing  with  the  standard 
peripherals,  the  process  peripherals,  the  sensors,  and  other  hardware 
devices.  These  facilities,  included  in  the  system  division  of  the 
program,  are  specified  by  the  programmer  for  each  specific  installation. 
The  problem  division,  containing  the  user's  application  program,  is 
machine  independent.  The  system  division  has  tc  be  modified  for 
different  comruters  or  installations.  It  allows  the  user  to  specify  the 
CPU  connections  with  the  devices  by  means  of  the  user-specified 
channels.  The  SINGLF  CONNECTION,  the  GPOIJP  CONNECTION,  and  the  TRANSFER 
DIRECTION  allows  specification  of  how  any  device  exchanges  data  with  any 
other  device. 
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No  conflict  with  other  requirements 
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61.  The  lanquage  will  provide  structured  control  mechanisms 
for  sequential,  conditional,  iterative,  and  recursive 
control.  It  will  also  provide  control  structures  tor 

(pseudo)  parallel  processino,  exception  handling,  and 

asynchronous  interrupt  handling. 

Sequential  execution  T 

Conditional  execution  T 

Iteration ...........................T 

Recursion  f 

(Ps»udo)  parallel  processing  ................................... ,T 

Fxcertion  handling  p- 

Asynchronous  interrupt  handling  ................................. T 

Control  structures  from  a small  set  of  simple  primitives  ,.F 


The  lanouaqe  provides  for  sequential  execution,  the  If  and  CASE 
statements  for  conditional  execution,  the  RFPEAT  statement  for 
iteration,  several  parallel  processing  features  for  creation, 
termination,  scheduling,  and  synchronization  of  tasks.  In  the 
event-dependent  scheduling  of  tasks,  an  event  can  be  an  interrupt  and 
the  language  allows  for  WHEN-CONDITION  and  ENABLE,  DISABLE/TRIGGER,  or 
INDUCE  options  to  handle  these  interrupts.  some  exception  conditions 
such  as  ON  end-of-file  and  ON  sional  are  provided  for,  although  no 
provision  is  made  in  the  language  for  many  other  exceptions  such  as 
overflow,  underflow,  zero  divide,  size,  subscript  ranqe,  strinn  range, 
area,  etc.  The  lanouage  does  not  provide  for  recursive  procedures. 
Hence  it  only  partially  meets  this  requirement. 

The  language  must  provide  for  recursive  procedures,  preferably 
oermiting  specification  of  a limit  on  the  depth  of  recursion.  Exception 
handlino  ON  conditions  for  various  situations  listed  in  the  previous 
paragraph  should  be  provided. 

Implementation  of  these  features  in  the  existing  compilers  will 
reouire  a moderate  effort. 


G2.  The  source  languaae  will  provide  a "GO  TO"  operation 
aorlicable  to  program  labels  within  its  most  local  scope  of 
definition.  ....P* 


A GOTO  statement  does  not  permit  a fume  into  a comrosed  entity  such 
as  a task,  procedure,  BEGIN  block,  REPEAT  statement,  conditional 
statement,  CASE  statements,  etc.,  since  such  entities  are  considered 
self-contained.  An  exit  from  the  block-tail  of  a task  or  procedure 
using  GOTO  is  also  not  permitted  fpp.  77-78).  However,  exits  from  BEGIN 
blocks  using  GOTO  are  not  explicitly  prohibited,  although  the  manual  has 
no  examples  of  such  a use. 
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Nc  conflict  with  other  requirements. 


G3-  The  conditional  control  structures  will  be  fully 
partitioned  and  will  permit  selection  among  alternative 
computations  based  on  the  value  of  a poolean  expression,  on 
the  subtype  of  a value  from  a discriminated  union,  or  on  a 


computed  choice  among  labeled  alternatives.  ....H 

Rased  on  Boolean  expression  T 

Based  on  type  from  discriminated  union  .......................... F 

°ased  on  computed  choice  among  labelea  alternatives  ............ .p 

All  alternative  must  be  accounted  for  ........................... F 

Simple  mechanisms  will  be  supplied  for  common  cases  T 


The  IF  statement  (p.  78)  allows  the  control  path  be  selected  based 
upon  the  evaluation  of  a Boolean  expression.  The  CASE  statement  permits 
a choice  from  among  its  latelled  statements  depending  upon  the  computed 
value  of  an  integer  expression  only.  It  also  provides  OUT  and  FIN 
statements  for  cases  when  the  integer  expression  is  negative  or  greater 
than  the  number  of  alternative  branches,  but  the  OUT  statement  is  not 
reauired  (p.  79).  Simplified  forms  of  these  statements  are  3lso 
permitted.  For  example,  an  IF  statement  need  not  have  FLSF  clause 
associated  with  it. 

The  lanouaqe  does  not  support  discriminated  union  at  all. 

The  CASE  statement  must  be  elaborated  to  permit  multiple  branches 
based  on  values  other  than  the  value  of  an  integer  expression.  As 
discriminated  union  is  added  to  the  lanouage  the  IF  and  CASE  statements 
should  be  modified  to  be  able  to  use  the  taa  field,  moderate  changes 
will  be  reauired  to  meet  this  requirement. 


G4.  The  iterative  control  structure  will  permit  the 
termination  condition  to  appear  anywhere  in  the  loop,  will 
require  control  variables  to  be  local  to  the  iterative 
control,  will  allow  entry  only  at  the  head  of  the  loop,  and 
will  not  impose  excessive  overhead  in  clarity  or  run  the 
execution  costs  for  common  special  case  termination 
conditions  (e.g.,  fixed  number  of  iterations  or  elements  of 
an  array  exhausted).  ....?♦ 

Termination  can  occur  anywhere  in  the  loop  ......................  T 

Multiple  termination  predicates  are  possible  I 
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Entry  permitted  only  at  the  loop  head  T 

Simple  cases  are  clear  and  efficient  ............................ T 

Control  variable  is  locel  to  the  loop  ........................... T 

Control  value  is  efficiently  available  after  termination . . F 


The  RFPFAT  statement  in  PEARL  comes  close  to  meeting  this 
requirement.  It  allows  termination  of  the  loop  at  any  point  by  means  o+ 
a GOTC'  cr  IF  statement,  it  only  allows  entry  to  the  loot  at  the  too,  and 
it  permits  simplification  (e.a.,  it  permits  values  o<  1 to  be 
substituted  for  expressions  following  FROM  and  BY  if  the  user  fails  to 
provide  a value  and  it  has  an  optional  WHILE  clause  for  a common 
terminating  case).  It  makes  the  control  variable  local  to  the  loop  and 
Guarantees  its  validity  within  it.  The  language  manual  also  specifies 
(o.  ?1)  that  the  value  of  the  control  variable  will  be  greater  than  the 
final  value  specified  by  the  expression  following  the  TO  clause. 
However,  that  value  is  inaccessible.  Indeed,  because  the  loop  variable 
is  local  to  the  loop,  its  value  can  only  be  accessed  outside  of  the  loop 
if  it  is  explicitly  assigned  to  some  other  variable  before  exit. 

The  lanauage  definition  should  srecify  that  the  value  of  the 
control  variable  be  available  to  the  user  after  the  termination  (normal 
or  abnormal)  of  the  loop.  Implementation  of  this  feature  is  trivial, 
the  hardest  part  being  finding  an  acceptable  syntax. 


G3.  Recursive  as  well  as  nonrecursive  routines  will  be 
available  in  the  source  language.  It  will  not  be  possible  to 


define  procedures  within  the  hody  of  a recursive 
orocedure.  ....F 

No  recursive  procedures  within  recursive  procedures  ............ .N/A 

(Maximum  depth  of  recursion  can  be  specified)  .................. .n /a 

(Recursiveness  must  be  specified)  .................. N/ A 


The  lanquaqe  does  not  support  recursion. 

Tbp  recursive  option  must  be  supported  by  the  language.  The 
default  should  he  no  recursion  so  that  the  user  does  not  pay  the  price 
for  recursive  code  if  he  does  not  need  it. 

* moderate  effort  will  be  required  to  provide  for  appropriate  code 
generation  for  recursive  procedures  and  for  related  interactions. 
Limits  on  the  levels  of  recursion  permitted  will  keen  the  stacks  and 
other  problems  to  manageable  sizes. 


PEAkL  S? 
Requirement  G6 

Gft.  The  source  lanauage  hill  provide  a parallel  processina 
capablity.  This  capability  should  include  the  ability  to 
create  ar.d  terminate  (possible  pseudo)  parallel  processes  and 
for  these  processes  to  qain  exclusive  use  of  resources  during 


specified  portions  of  their  execution.  ....P 

Able  to  create  and  terminate  parallel  processes  .......T 

Process  C3n  qain  exclusive  use  of  resources  .......P 

No  parallel  routines  within  recursive  routines  N/A 

No  routines  within  parallel  rcutines  ............................ T 

Maximum  number  of  simultaneous  instances  are  declarable  f 

(Access  rules  are  enforced)  .F 


Thp  language  allows  parallel  processing  capabilities.  It  permits 
the  creation  of  a task  hy  means  of  task  declaration,  its  activation  by 
means  of  the  ACTIVATE  statement,  continuation  by  means  of  the  CONTINUE 
statement,  temporary  suspension  by  means  of  the  SUSPEND  statement,  and 
termination  by  means  of  the  TERMINATE  statement  <pp.  133,  139-146).  The 
task  can  only  be  declared  at  the  module  level.  That  is,  there  can  pe  no 
task  declaration  within  a procedure  declaration,  or  within  a task 
declaration.  Thus  subtasks  are  rot  permitted.  There  is  no  provision  in 
the  lanouaqe  to  lock  out  files  or  records  to  prevent  simultaneous  access 
by  two  or  more  parallel  tasks,  tut  semaphore  variables  are  available  to 
simulate  this  capability  in  many  cases.  The  language  also  does  no* 
allcw  specification  of  the  maximum  number  of  parallel  tasks,  since  the 
language  does  not  permit  recursion,  the  user  cannot  define  parallel 
routines  within  recursive  routines. 

To  fully  meet  this  requirement  the  lanquaqe  should  allow  certain 
facilities  to  temporarily  lock  out  3 file  or  other  resources  for 
exclusive  use  by  a certain  task.  The  lannuage  should  also  allow  the 
user  to  specify  the  maximum  number  of  parallel  tasks  permissible  at  any 
one  time. 

The  file  handlinq  capabilities  of  the  lanquaqe  should  be  modified 
to  include  an  'EXCLUSIVE'  option  to  allow  a task  exclusive  use  of  that 
file  until  the  resource  is  released.  A moderate  amount  of  effort  will 
be  needed  to  effectively  implement  these  features  in  the  existing 
compi l ers . 


G 7 . The  exception  handlinq  control  structure  will  permit  the 
user  to  cause  transfer  of  control  and  data  for  any  error  or 


exception  situation  which  miaht  occur  in  a proqram.  ....P- 

Program  can  get  control  for  any  exception  P- 

rara meters  can  be  rassed  f 

Can  get  out  of  any  level  o*  a nest  of  control  ...................  f 


PE  AKL 

rtf*  ill  i re  Tent  6/ 


3 3 


Can  handle  the  exception  at  any  level  of  control  F 


The  language  does  not  provide  for  exception  handlinq  capabilities, 
except  for  the  end-of-file  capabilities.  No  provision  is  made  to  allow 
the  user  to  control  the  flow  of  the  program  in  case  of  overflow, 
underflow,  zero  divide,  subscript  range  error,  size  error,  etc. 
Exception  handlinn  parameters  (e.g.,  labels)  are  not  permitted  to  be 
passed  in  procedure  calls. 

The  entire  control  structure  associated  with  'ON'  conditions  tor 
error  and  exception  handling  must  be  added  to  the  language.  These 
structures  should  allow  the  user  to  terminate,  resume  or  retry 
operations,  permit  constraints  in  flow  of  control,  and  in  certain  cases 
should  permit  exceptions  by  default. 

A moderate  to  significant  amount  of  effort  will  he  required  to 
include  these  features.  These  will  affect  the  existing  language  syntax 
and  code  generation  procedures. 


ft t.  There  will  be  source  lanquaqe  features  which  Dermit 
delay  on  any  control  path  until  some  specified  time  or 
situation  has  occurred,  which  permit  specification  of  the 
relative  priorities  atnonc  parallel  control  paths,  which  give 
access  to  real  time  clocks,  which  permit  asynchronous 
hardnare  interrupts  tc  be  treated  as  any  other  exception 


situation.  . . . . Ps 

Priority  specification  T 

Synchronization  via  wait/enalle  operations  ...................... T 

wait  for  end  of  real  time  interval  F 

wait  for  end  cf  simulated  time  interval  ......................... F 

Wait  for  hardware  interrupt  ...........T 

(Car  enable  and  disable  interrupts)  .............................  T 


The  language  almost  meets  this  requirement,  lacking  only  the 
ability  to  use  simulated  time.  The  task  declaration  includes  a 
specification  of  PRIORITY  and  permits  a task  to  wait  until  the 
completion  of  ar  event  or  a time  duration  before  reactivating. 
Time-related  events  can  occur  at  specified  times  or  after  specified 
intervals.  The  lanouane  also  permits  FNAPLE  and  DISABLF  options  to 
enable  or  disable  or  induce  certain  interrupts  (pp.  133-150).  special 
semaphore  variables  ere  provided  to  allow  task  synchronization  when  used 
with  the  REOUEST  and  RELEASE  operations. 

No  conflict  with  other  requirements. 
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Hi.  The  source  lanouaoe  will  be  tree  format  with  an  explicit 
statement  delimiter,  will  allow  the  use  of  mnemonically 
significant  identifiers,  will  be  based  on  conventional  forms, 
will  have  a simple  uniform  and  easily  parsed  grammar,  will 
not  provide  unique  notations  for  special  cases,  will  not 
permit  abbreviation  of  identifiers  or  key  words,  and  will  be 


syntactically  unambiguous.  ,...P* 

Free  Forma*-  with  statement  terminator  ........................... P* 

Mnemonic  identifiers  possible  ................................... T 

Rased  on  conventional  forms  ..................................... T 

Simple  grammar  T 

No  special  case  notations  T 

No  abbreviations  of  identifiers  or  keywords  F 

Unambiguous  nrammar  P+ 


The  F'FARL  lanouaoe  permits  free  formattino  of  its  statements  and 
requires  a semi-colon  to  terminate  them.  The  only  exception  to  the  rule 
is  that  blanks  are  not  allowed  in  the  composite  operators  (e.g.,  ==,  >=, 
**  etc).  The  lanouaoe  allows  the  user  to  specify  mnemonic  names 
although  it  permits  the  compilers  to  scan  only  the  first  six 

alphanumeric  characters  to  establish  the  uniqueness  of  the  identifiers. 
The  lanouaqe  constructs  are  in  aeneral  readable  and  permit  a left  to 
right  scan  of  statements.  Rules  for  expression  evaluation,  parameter 
passing  and  ether  salient  features  of  the  language  are  simple  and  easily 
understood.  There  are  no  special  language  constructs  to  support  rare 
cases.  The  languaae,  however,  permits  abbreviations  for  some  of  its 
keywords.  For  instance  the  abbreviations  DVC,  SPC,  DCL,  INIT  and  prjo 
are  permitted  to  represent  DEVICE,  SPECIFY,  DECLARE,  INITIAL,  and 
PRIORITY  respectively.  Furthermore  the  language  provides  clear  syntax 
with  few  exceptions.  For  exarrrle,  the  constructs  RETURN  and  RETURNS  are 
syntactically  very  close  to  each  other,  yet  have  two  separate  and 
distinct  functions  to  perform.  One  is  used  to  return  the  value  of  the 
function  while  the  other  is  used  to  define  the  mode  of  the  function 
value.  Two  distant  syntax  entities  should  be  used  to  perform  these 
; f unct i ons . 

Minor  modifications  to  the  language  syntax  are  needed  to  fulfill 
this  requirement.  Abbreviations  fnr  keywords  should  be  forbidden. 
Those  keywords,  such  as  RFTURN  and  RETURNS,  which  are  syntactically  very 
similar  and  yet  perform  two  different  functions,  should  be  altered  and 
made  syntactically  distant. 

Inclusion  of  these  modifications  in  the  existing  compilers  is 
trivial.  It  may  impact  the  user  programs  more  severely. 


H? . The  user  will  not  be  ablr  to  modify  the  source 


language 
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syntax.  Specifically,  he  will  not  be  able  to  modify  operator 
hierarchies,  introduce  new  precedenc?  rules,  define  new  key 
word  forms  or  define  new  infix  operator  precedences.  ....T 


The  language  definition,  its  features  and  rules  do  not  allow  the 
user  any  means  to  alter  the  lanouaqe  syntax.  He  cannot  alt<*r  operator 
hierarchies,  precedence  rules,  define  new  keywords  or  infix  operations. 
The  rrost  he  is  allowed  to  chanoe  is  a few  special  characters  which  are 
installation  dependent.  This  may  alter  parts  of  his  proararr.s,  but  dnes 
not  affect  the  language  defined  constructs. 

No  conflict  with  other  requirements. 


H3.  The  syntax  cf  source  language  programs  will  be 
comrosable  from  a character  set  suitable  for  publication 
purposes,  l ut  no  feature  of  the  tenguage  will  be  inaccessible 
usirn  the  64  character  ASCII  subset.  ....P 


All  language  constructs  are  composed  of  a character  set  consisting 
of  P6  alphabetic  characters  (A-?),  10  numeric  characters  fd-0),  and  15 
special  characters,  which  are  all  part  of  the  ASCII  character  set.  The 
lanquaqe  dees,  however,  prrvide  for  installation  defined  special 
characters,  some  or  all  of  which  may  not  be  formed  from  the  64  character 
ASCII  set.  (p.  31) 

A further  constraint  should  be  placed  on  the  installation  dependent 
character  set  requiring  that  no  special  characters  that  cannot  be  formed 
from  the  standard  64  character  ASCII  set  should  be  permitted  in  tbe  set. 
Even  better  would  be  to  forbid  any  installation  dependent  characters. 

Implementation  of  this  constraint  is  trivial. 


H4 . The  lanauaoe  definition  will  provide  the  formation  rules 
for  identifiers  and  literals.  These  wilt  include  literals 
for  number*:  and  character  strinas  and  a break  character  for 


use  internal  tc  identifiers  and  literals.  ....p 

Break  character  exists  F 

(literals  are  sel f -ident i f yi no  as  to  type)  T 

(Pit-strinn  literals  for  any  type)  F 
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The  language  provides  the  formation  rules  for  identifiers  and 
literals  (pp.  32-3P).  It  dors  not,  however,  provide  for  a break 
character  which  can  he  used  to  increase  the  readability  of  the 
identifiers.  in  fact,  it  explicitly  fortids  the  use  of  blanks  and 
special  characters  for  use  within  identifiers. 

The  formation  rules  for  identifiers  and  literals  should  be  modified 
to  include  the  use  of  certain  language  specified  break  characters.  This 
would  increase  the  readability  of  language  constructs.  Perhaps  the 
number  of  characters  establish  uniqueness  of  the  identifiers  should 
also  he  increased  from  6 to  at  least  12. 

Imolementation  of  these  suggested  changes  to  the  language  will 
affect  most  existinn  translators  but  its  scope  will  be  minor. 


M 5 . There  will  be  no  continuation  of  lexical  units  across 
lines,  but  there  will  be  a way  to  include  object  characters 
such  as  end-of-line  in  literal  strings.  ....F 


Nowhere  does  the  language  manual  specifically  permit  identifiers, 
constants,  etc.,  to  be  continued  across  lines.  However,  The  manual 
explicitly  states  that  comments  or  its  nortions  can  be  carried  across 
lines,  implying  that  the  same  rule  is  permissible  to  lexical  entities 
also.  (o.  37) 

The  manual  should  explicitly  forbid  the  continuation  of  lexical 
entities  across  lines. 

Minimal  changes  tc  existinn  implementations  will  be  required  to 
accommodate  this  language  modification. 


H 6 . Key  words  will  be  reserved,  will  be  very  few  in  number, 
will  he  informative,  and  will  not  he  usable  in  contexts  where 
an  identifier  can  he  used.  ....P 


The  keywords  in  the  language  are  reserved  and  cannot  he  used  as 
identifiers.  however,  the  number  of  keywords  is  not  small  (IS?).  As  a 
rule  these  keywords  are  informative.  (See  anoendix  A?. 3.) 

part  of  the  reason  for  such  a laroe  number  of  keywords  is  that  manv 
of  the  keywords  have  abbreviations  which  are  also  treated  as  keywords. 
If  the  bbreviatii  ns  were  eliminated,  as  suggested  in  requirement  Hi, 
the  list  cf  keywords  can  he  siani* icnnt ly  reduced. 
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"initial  effort  is  requires  to  implement  this  change. 


H7.  Tre  source  lanquaoe  will  have  a single  uniform  comment 
convention.  Comments  will  no  easily  distinguishable  from 
code,  will  be  introduced  by  a single  (or  possibly  two) 
language  defined  characters,  will  permit  any  combination  of 
characters  to  appear,  will  be  able  to  appear  anywhere 
reasonable  in  programs,  will  automatically  terminate  at 


end-of-line  if  not  otherwise  terminated,  and  will  not 
prohibit  automatic  reformatting  of  programs.  ,...P«- 

Uniform  comment  convention  .T 

Look  different  from  code  T 

bracketed  by  one  or  two  characters  .......... ....................T 

Can  contain  any  characters  ..................................... .T 

Can  appear  anywhere  reasonable  T 

Terminated  by  the  end  of  the  li^e  ............................... F 

Compatible  with  automatic  reformatting  .......................... T 


The  language  allows  a single  uniform  comment  convention.  These 
comments  can  be  easily  inserted  into  the  proqram  text  between  language 
elements.  They  must  be  delimited  by  /*  and  */.  Any  single  character 
can  be  included  in  the  comment,  only  the  */  combination  is  excluded 
since  it  sionities  termination  of  the  comment.  The  language  definition, 
however,  permits  continuation  of  comments  over  several  lines  and  does 
not  require  their  termination  at  the  end  of  the  line.  These  comment 
conventions  do  not  prohibit  automatic  reformatting  of  programs, 
(po.  37-38) 

Tc  meet  this  requirement  the  lanquaoe  must  reauire  that  the  comment 
terminate  at  the  end  of  line  in  addition  to  terminating  at  */ 
combination. 

Minimal  implementation  charges  are  required  to  incorporate  this 
language  chanqe. 


HR.  The  language  will  not  permit  unmatched  parentheses  of 
any  kind.  ....T 


PEAHl  fully  meets  this  requirement. 
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H9.  There  will  be  a uniform  referent  notation.  ....F+ 


Function  references  and  array  element  references  have  similar 
notation  in  PFJRL,  the  erouments  beinq  enclosed  in  parentheses. 
However,  assignment  to  a function  is  not  possible.  Since  functions 
cannot  return  structure  values,  the  question  of  dot  qualification  of  a 
function  name  does  not  arise. 

To  allow  assignment  tr  a function  would  te  a moderate  effort. 


Hi  0 . No  lanquaqe  defined  symbnls  appearing  in  the  same 
context  will  have  essentially  different  meanings.  ....T 


The  language  assigns  unique  meanino  to  its  symbols.  The  usaqe  of 
its  symbols  is  unambi oucus . For  example  the  symbol  = is  used  for 
assinnment  while  =*  is  used  for  lonical  eouality  comparisons.  There  is, 
however,  redundancy  in  symbols.  Both  :=  and  * are  used  for  assignment. 

The  redundancy  in  the  lanquaqe  operators  should  be  eliminated  by 
simply  disallowing  one  symbol  to  be  used  in  the  lanquage.  This  will 
increase  the  efficiency  of  the  lenauage. 

Minimal  implementation  changes  will  be  reauired  in  the  syntax 
checking  mechanism  and  the  symbol  table  to  affect  this  lanquage 
mndi f i cat  ion . 
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II.  TF'ers  will  be  no  defaults  in  programs  which  affect  the 
oronram  loaic.  That  is,  decisions  which  affect  program  loqic 
will  he  made  either  irrevocably  trhen  the  language  is  defined 
or  explicitly  in  each  proorani.  ....P 


In  many  instances  the  defaults  are  language  defined.  For  instance, 
if  a procedure  is  not  explicitly  declared  REENTRANT,  the  automatic 
default  is  that  it  will  be  treated  like  a nori-reent r ant  procedure  which 
will  rot  be  callable  simultaneously  fro*  two  or  more  tasks.  Similarly, 
in  the  SEND  or  TAKE  statements  if  the  user  fails  to  specify  the  SY130L 
(the  location  of  buffer)  option,  the  default  is  assumed  to  be  the 
storage  cell  or  arrav  assigned  to  the  I/O  device.  However,  in  many 
other  instances  the  language  fails  tc  define  the  default  condition  and 
leaves  it  implementation  deoendert.  For  example,  no  exception  handling 
mechanisms  are  provided  in  the  lanquage.  Hence,  the  action  taken  or  the 
flow  of  control  after  an  overflow,  underflow,  size  error,  suhscriot 
range  error,  etc.,  is  implementation  dependent.  Similarly  the  language 
does  not  provide  lockout  facilities  for  file  control.  In  parallel 
processing  situations  when  two  or  more  tasks  vie  for  the  same  file  at 
the  same  tine,  what  happens  is  undefined.  The  language  fails  to  specify 
ways  to  prevent  such  deadlock. 

The  languaqe  must  carefully  specify  a means  for  handling  exception 
conditions  or  list  the  default  actions  that  compilers  must  take  when 
exception  situations  arise.  In  rarallel  processing  also,  tile  lockout 
and  other  mechanisms  should  be  provided  to  avoid  deadlocks  or 
simultaneous  access  of  the  same  file  by  two  or  more  tasks  when  that  is 
not  desired. 

Implementation  of  these  facilities  will  require  moderate  additions 
to  existinq  compilers.  The  syntax  handling  routines,  task  handling 
routines,  and  I/O  handlinc  routines  will  have  to  be  modified.  Exception 
handling  capabilities  will  have  to  be  added. 


lil.  Defaults  will  be  provided  for  special  capabilities 
affecting  only  object  representation  and  other  properties 
which  the  programmer  does  rot  know  or  care  about.  Such 
defaults  will  always  mean  that  the  oroorammer  does  not  care 
which  choice  is  made.  The  programmer  will  be  able  to 


override  these  defaults  when  necessary.  . . . . P 

Defaults  specified  for  oon't  care  cases  T 

Programmer  can  override  the  defaults  F 


The  lanquaqe  permits  a large  number  of  defaults  to  be  taken  care  of 
by  implementations.  These  are  "don't  care"  types  of  defaults.  They 
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include  such  cases  in  which  a rrccedure  is  treated  as  non-reentrant  if 
the  kF  ENTRANT  option  is  not  provided,  the  sire  of  an  input  record  in 
stream  type  of  in^ut,  etc.  Put  other  types  of  defaults  which  affect  the 
result  or  the  flow  of  control  of  the  proqram  are  not  "don't  care"  type 
of  defaults.  This  category  includes  provisions  for  exception  handling, 
sjbscrirt  range  checking,  etc.  The  language  does  not  allow  the  user  the 
facility  to  override  these  types  of  defaults. 

The  chanqes  necessary  to  give  an  ability  to  override  these 
exceptional  defaults  are  discussed  under  reauireirent  (->7. 


13.  The  user  will  he  able  to  associate  compile  time 
variables  with  programs.  These  will  include  variables  which 
specify  the  object  computer  model  and  other  aspects  of  the 
object  machine  configuration.  ....T 

PEARL  provides  the  user  the  facility  to  specify  the  configuration 
characteristics  of  the  hardware  system  necessary  to  execute  his  problem 
program.  This  is  done  by  means  of  the  svstem  division  in  which  the  user 
describes  the  hardware  conf iouration,  the  standard  peripherals,  the 
process  peripherals,  the  device  connections,  the  sensors,  interruots, 
and  signals.  PEARL  enables  the  programmer  to  declare  problem  specific 
designators  for  devices  and  device  connections  which  can  then  reaaily  be 
used  in  the  problem  division  of  his  prooram.  Thus  a meaninoful 
declaration  of  tbe  process  dependent  data  is  guaranteed.  Arother 
advantage  of  this  facility  is  that  whenever  changes  in  the  hardware 
configurations  have  to  be  made,  they  can  be  restricted  only  to  the 
system  division  without  modification  to  the  problem  division. 
Furthermore,  the  rystem  division  of  a PEARL  program  provides  for  the 
automatic  generation  of  a problem  specific  executive  system. 

ho  conflict  with  other  reauirements. 


I A . The  source  language  will  permit  the  use  of  conditional 
statements  (e.g.,  case  statements)  dependent  on  the  object 
environment  and  other  compile  time  variables.  In  such  cases 
the  conditional  will  le  evaluated  at  compile  time  and  only 
the  selected  path  will  h compiled.  ...,F 


PFARL  has  no  conditional  compilation  capability. 
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The  lanoua^e  designer  must  consider  proviriina  tor  such  conditional 
compilation  tacilities.  They  should  also  establish  as  to  where  in  the 
program  the  user  must  specify  conditional  expressions  which  are  compile 
ti^e  evaluable.  The  result  of  the  evaluation  will  then  decide  which  of 
the  several  environments  that  are  possible  for  the  program  should  be 
generated. 

This  facility  can  usually  be  implemented  in  most  compilers  at  a 
modest  cost,  the  cost  deperdinq  primarily  on  the  source  level 
elaborateness  o*  the  facility.  The  required  changes  usually  can  oe 
isolated  in  the  initial  phase  of  the  compiler. 


15.  The  source  lannuage  will  contain  a simple  clearly 
identifiable  base  or  kernel  which  houses  all  the  power  of  the 
lanouace.  To  the  extent  possible,  the  base  will  be  minimal 
with  each  feature  providino  a single  unique  capability  not 
otherwise  duplicated  in  the  base.  The  choice  of  the  base 
will  not  detract  from  the  efficiency,  safety,  or 

untferstandabi l ity  of  the  lanowage.  ,...u 


Th*>  language  manual  does  not  recoqnize  nor  clearly  specify  the 
avionic  subset  of  the  PFAPL  language  as  the  kernel  of  the  overall  pearl 
languaoe.  The  preface  to  the  marual  states  that  there  are  commonalities 
between  'avionic  subset'  and  'PEARL-Basis-Suhset ' . However,  a list  of 
tnose  commonalities  which  may  possibly  constitute  the  kernel  of  the 
language  is  not  available.  Furthermore,  to  eualify  as  the  kernel  cf  the 
language,  these  'commonalities'  cf  the  language  must  be  sufficient  so 
that  their  implementation  alone  will  make  the  full  sourre  lanquaqe 
capability  available  through  extensions. 

The  kernel  of  the  languaae  which  contains  all  the  power  of  the 
languaoe  must  be  identified.  The  other  language  capabilities  should  be 
definable  and  imr lementab  le  in  terms  of  the  features  of  the  kernel. 

A moderate  amount  of  effort  will  be  necessary  to  define  the  kernel 
of  the  language  it  one  does  not  exist  at  present. 


I*.  Language  restrictions  which  are  dependent  only  on  the 
translator  and  not  on  the  object  machine  will  be  specified 
explicitly  in  tne  languaoe  definition.  ....P 


1 
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The  lanouaoe  specifies  few  limits  on  its  features  which  arc 
basically  machine  independent . for  instance,  it  renuires  that 
identifiers  he  6 alphanumeric  characters  lonn.  However,  it  does  not 
specify  limits  on  several  other  lanouaoe  constructs.  For  instance, 
there  is  no  lanquage  specified  limit  on  the  number  of  dimensions  of  an 
array,  on  the  maximum  number  of  REPFATs  within  REPEATS,  IFs  within  lfs, 
the  maximum  number  of  identifiers  in  a procedure  or  proqram,  the  maximum 
number  of  statements  in  a procedure,  maximum  number  of  formal  and  actual 
parameters,  etc.  Hence,  it  cnly  partially  meets  this  requirement. 

To  implement  this  chanoe  would  require  analysis  of  user 
requi rements  and  e st aD l i s hment  of  limits  tor  various  features,  such  as 
the  ones  listed  in  the  previous  raranrarf,  so  that  these  limits  will  not 
be  exceeded  by  any  application.  The  effect  of  such  standar.fi  ?ed 
limitations  on  existing  implementations  which  meet  or  exceed  then  will 
be  minimal,  but  the  effect  on  other  inolrmentations  could  be  heavy. 


17.  Lannuaqe  restrictions  which  arc  inherently  dependent 
only  on  the  object  environment  will  not  be  built  into  the 
lanouaqe  definition  or  any  translator.  ....T 


The  lanauaqe  does  not  contain  restrictions  which  have  been  imposed 
by  the  hardware  or  object  environment  with  the  possible  exception  of 
CLOC*  data  tyt e and  related  features  which  require  access  to  ? real-time 
clock.  However,  this  is  an  essential  feature  to  support  the  real-time 
capabilities  of  the  lanquaoe.  Tie  lanouaoe  does  not  put  limits  on  run- 
time storaoe  requirements  or  the  type  or  number  of  peripherals  or  other 
special  hardware  oevices. 

A'o  conflict  with  other  requirements. 


J 
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Jl.  The  lanyuaoe  and  its  translators  will  not  impose  run 
tiT*'  costs  4or  unneeded  or  unused  Generality.  They  will  be 
capable  cf  producinq  efficient  code  for  all  programs.  ....P 

*c  efficiency  cost  for  unused  features  ......................... .P 

rfficient  code  can  be  produced  for  all  features  ................. P 


There  are  some  features  of  the  lanouage  which  iray  be  costly  in 
terms  of  run  time  or  code  even  when  not  used.  Procedure  calls  ere  one 
such  example.  There  is  no  provision  for  a NORFCALL  option  for 
procedures  which  can  save  execution  time.  The  user  is  not  allowed  the 
option  cf  OP  F N or  CLO'ED  procedures  and  is  thus  forced  to  pay  for  closed 
calls. 


R'odi  f i cat  ions  to  Unnuaae  features  to  include  OPFN,  CLOSED, 
NORFCALL  anri  similar  other  optimizing  features  in  the  language  will 
increase  the  compilers'  capability  tc  generate  efficient  code. 
Implementation  of  these  capabilities  will  reouire  a moderate  amount  of 
effort  in  the  code  ceneration  and  syntax  analysis  portions  of  the 
comoi l er . 


J 2.  Any  optimizations  performed  by  the  translator  will  not 
change  the  effect  cf  the  pronram.  . . . . U 


This  is  basically  a translator  requirement.  However,  certain 
features  of  the  language,  such  as  the  REENTRANT  option,  permit  the 
translators  to  generate  non-reentrant  code  in  their  absence.  It  permits 
generation  of  more  efficient  code  without  changing  the  effect  of  the 
program. 

The  reouirement  is  more  applicable  to  the  translators  than  to  the 
languages.  Lanquages  can,  however,  provide  certain  features  (e.q., 
OPF N,  NORFCALL,  PACKINC  of  data  etc.)  which  can  permit  optimization  of 
space  ana/or  time. 


J3.  The  source  lancuaoe  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  including  machine 
lannuaoe  code  insertions.  ...«P 


The  system  division  of  PFARL  provides  encapsulated  access  to 
machinp  dependent  lardware  facilities.  The  user  has  control  of  device 
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management  and  connections.  He  can  control  I/O  channels  and  associate 
then  with  desired  peripheral  devices.  He  can  also  handle  certain 
hardware  interrupts  and  sinnals.  He  can  address  these  devices, 
interrupt?,  etc.,  in  the  problem  division.  (pp.  100-109) 

However,  PEARL  does  not  specify  interfaces  with  machine  code  in  any 
way.  This  interface  is  either  not  defined  or  can  be  achieved  by  a 
procedure  call  to  a machine  language  procedure.  The  language  manual 
does  rot  specify  that  descriotion  of  machine  characteristics  for  which 
tne  machine  code  is  being  introduced  be  present  in  the  code. 

The  language  manual  should  clearly  state  how  the  interface?  with 
the  assembly  language  procedures  ere  to  be  established  includinq  the 
details  of  the  format  for  such  a call. 


JA.  It  will  be  possiblr  within  the  source  language  to 
specify  the  object  presentation  of  composite  data  structures. 
These  descriptions  will  be  optional  and  encapsulated  and  will 
be  distinct  from  the  logical  descriotion.  The  user  will  be 
able  to  specify  the  time/srace  trade-off  to  the  translator. 
If  not  specified,  the  object  representation  will  be  optimal 


as  determined  by  the  translator.  . . . . F 

Encapsulated  specification  of  represertat ion  possible  ...........F 

Space/time  tradeoff  can  be  specified  F 


The  language  does  not  allow  packina  factors  to  he  specified  with 
the  data  structures,  nor  does  it  allow  the  length  of  each  field  to  be 
specified  in  the  structure.  The  lanquaoe  does,  however,  permit  length 
specifications  for  fixed  point  and  floating  point  data.  No  facility  in 
the  language  is  provided  to  specify  a space/time  tradeoff  to  the 
compiler.  <pd.  S 4 ) 

The  language  data  structure  definition  should  allow  packing  of  data 
as  well  as  the  user  specification  of  field  length.  Other  space/time 
tradeoff  directives  should  also  be  included  in  the  language  which  will 
permit  the  compiler  to  try  to  optimize  for  space  or  run-time  wherever 
possible. 

The  existing  translators  will  have  to  be  modified  to  accept  and 
process  the  lanquaae  space/time  related  directives.  They  will  have  to 
be  modified  to  provide  for  new  data  structure  definitions. 


L A 
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J5.  The  pronrammer  will  he  able  to  specify  whether  calls  on 
a routine  are  to  have  an  open  or  closed  implementation.  An 
open  .and  a closed  routine  of  the  sam*>  description  will  have 


identical  semantics.  ...,F 

Oner / c losed  properties  can  be  specified  .....F 

Oper.  and  closed  versions  have  the  same  semantics  ......... .......F 


The  lanouaoe  does  not  provide  this  option  to  the  user. 

The  procedure  definition  should  be  modified  to  permit  OPfN  or 
C LOS f h notion  to  he  provided  by  the  user.  All  existino  implementations 
will  bavf  to  be  »>odi*ied  to  include  this  option.  The  cost  will  be 
•noderate  to  high. 
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Extraneous  features 


We  recommend  th<st  the  fol loving  -features  of  PEARL,  not  required  by 
the  Tinman,  be  kett: 

* CHAR  (character  string)  type  and  the  CAT 

(concatenation)  operator  (assuming  that  the  Tinman 
requires  only  a character  type,  not  ? character  strim 
type) . 


* CLOCK,  CUR,  DEVICE,  FILL,  INTERRUPT,  SIGNAL,  and  SE»U 
types.  Although  not  explicitly  called  for  by  the 
Tinman  as  types,  they  are  reeded  in  the  PEARL 
realization  of  other  Tinman  requirements  (e.c., 
parallel  orocessing,  dpvice  independence). 

* Call  by  value  parameters. 


We  recommend  that  the  following  features  of  PEARL,  not  required  by 
the  Tinman,  be  Deleted: 


The  LENGTH  olobal  specification  and  cata  attribute. 
These  functions  will  be  assumed  by  range  and  precision 
specifications  in  any  extension  of  PEARL  to  meet  the 
Tinman  requi rements . 


* The  FIT  operator.  The  function  of  and  need  for  this 
operator  (which  "fits"  an  integer  of  one  tenqth  to 
another  length)  are  unclear,  but  it  appears  that  if 
range  specification  dor  integer  data  is  added  to  the 
language,  as  called  for  by  the  Tinman  reoui rements , 
then  it  will  not  be  needed  because  explicit  conversion 
between  ranges  is  unnecessary,  according  to 
requirement  R8. 

* The  SKIP  statement.  Ibis  is  a hioh-level  no-op  and 
PEARL,  unlike  Fortran,  has  no  need  for  such  a 
statement.  It  could  functionally  be  replaced  by  a 
comment . 

The  two  shift  operators  (SHIFT  and  CSHIFT)  perform  a useful  function, 
but  their  uses  are  almost  always  hardware  dependent.  Therefore  any  use 
should  be  bracketed  (encapsulated)  by  statements  which  call  attention  to 
that  dependency.  This  is  particularly  true  tor  CSHIFT  (circular  shift), 
which  is  often  implemented  in  a hiohly  dependent  fashion.  (It  is 
difficult  to  functionally  simulate  a circular  shift  in  a datum  which 
occupies  only  part  of  a hardware  register.) 
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Summary 

PEARL  supports  several  of  the  real-fine  capabilities  called  fcr  in 
the  Tinman  completely  or  partially.  It  provide?  for  input/output 
capabilities.  The  user  has  control  of  channel  programming,  device 
assignment,  interrupt  handling,  and  signal  handlinq.  He  can  access  and 
manipulate  files.  He  can  perform  graphic  input  or  output.  The  language 
also  provides  fcr  parallel  processing  features.  There  are  language 
constructs  fcr  multiple  task  creation,  termination,  resumrt ion, 
synchronization,  anc  continuation.  The  user  can  assign  priorities  to 
his  tasks.  Me  can  establish  communication  between  these  tasks.  The 
lamuaae  also  supports  real-time  processing.  Two  data  types  ( CLOCK  and 
Dll R ) are  provided  in  the  lanouage  to  account  tor  real-time  ano  time 
duration.  Tie  taskinq  facility  is  combined  with  real-time  options  to 
start,  delay,  or  terminate  tasks  at  certain  arpointe^  times  nr  after 
certain  time  durations. 

In  addition,  the  lanquace  supports  many  other  Tinman  requirements. 
It  requires  explicit  declaration  ot  tyre  for  all  entities  at  the 
beginning  of  their  scope  and  before  their  use.  it  provides  for  numeric, 
character,  clock,  duration,  array,  and  structure  data  types.  It  allows 
explicit  mode  conversions  between  different  data  types  by  providing 
conversion  operators  (e.o.  fix,  FLOAT,  CHAR,  TIT,  etc.).  It  allows 
global  specification  of  the  lenoth  ano  mantissa  for  fixed  point  and 
floating  point  variables.  It  requires  that  the  numher  of  dimensions  of 
arrays,  their  type,  and  their  lower  bound  he  fixed  at  compile  time, 
although  it  permits  dynamic  arrays  whose  upper  bounds  can  be  determined 
at  score  entry  time.  It  allows  establishment  of  equivalence  between 
variables  oy  means  of  the  IPFNT  attribute.  The  lanouaqe  syntax  permits 
differentiation  between  assianment  ana  logical  equivalence  ano  provides 
for  various  logical  comparison  operations.  Checkinq  for  type  and  number 
of  actual  and  formal  parameters  is  recuired  in  the  lanquage  def -*nition, 
as  are  calls  by  value  and  reference.  The  lanquage  allows  an  identifier 
to  stand  fcr  a constant.  It  provides  for  data  initialization  as  part  ot 
data  declarations  and  does  not  permit  declarations  by  default. 
Additionally,  the  lanouaqe  provides  a special  capability  for  specifyinq 
the  name  of  a library  into  which  the  files  or  procedures  are  to  De 
stored. 

Despite  these  characteristics  that  the  lanquage  possesses,  there 
are  others  in  which  the  lanouace  is  deficient.  It  does  not  have  a fixed 
point  data  type.  It  does  not  provide  for  user-defined  data  types  or 
operators,  nor  does  it  allow  extension  of  existing  operators  to  new  data 
types.  The  language  also  does  not  sufport  the  notion  of  defininq  new 
data  types  by  enumeration  or  as  rartesian  products,  discriminated 
unions,  or  powersets.  Another  significant  deficiency  in  the  lanouaqe  is 
the  aPsence  of  any  kind  of  pointer  mechanism  which  can  enable  a user  to 
nanipulate  lists  and  recursive  data  tyres.  Recursion  at  procedure  level 
is  also  not  supported  in  tbe  lanquage.  Furthermore,  there  are  no 
exception  handling  control  mechanisms  in  the  languaqe  to  control 
subscript  ranoe  error,  size  error,  overflow,  underflow,  etc.  No  less 
significant  is  the  lack  of  a well  defined  interface  with  routines 
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comniled  fro-*  assembly  language  and  other  high  oraer  languages.  The 
Language  also  fails  to  provide  for  mechanisms  to  control  compilations  to 
generate  code  for  specific  hardware  environments. 

In  addition  to  the  major  omissions  listed  in  the  previous 
paragraph,  the  language  fails  to  meet  the  Tinman  requirements  in  some 
other  ways.  It  does  not  provide  for  precision  and  range  specification 
of  variables  at  the  time  o*  their  definition.  There  is  no  provision  for 
the  operation  of  integer  division  with  remainder.  The  languane  does  not 
require  that  all  truncation  durinn  compilation  take  place  only  from  the 
least  significant  bits  on  the  right.  Scalar  operations  on  compatible 
arrays  and  records  as  a whole  are  not  defined.  Constant  expressions 
cannot  replace  constants  anywhere  in  the  program,  in  particular  in  the 
declarations.  The  language  does  not  require  that  the  value  of  the 
control  variable  in  a loop  te  available  after  normal  or  abnormal 
termination  of  the  loop.  Several  keywords  have  alternate  abbreviated 
forms.  There  is  no  language  defined  break  character,  and  the  language 
does  not  provide  the  user  the  option  to  specify  open  procedures. 

Although  a sionificant  amount  of  effort  will  be  required  to  modify 
the  language  definition  and  syntax  and  to  extend  the  capabilities  of  the 
present  definition  of  the  languane  to  include  those  features  in  the 
language  required  by  Tinman,  we  believe  that  such  an  effort  can  be 
successful.  with  the  excellent  I/O,  tasking,  real-time  and  hardware 
interface  capabilities  that  the  language  currently  possesses,  an 
extended  language  to  meet  the  future  POP  requirements  can  be  built. 
Portions  of  the  existing  syntax  will  have  ».o  be  modified,  others 
eliminated  and  some  new  ones  added.  However,  the  language  does  contain 
enough  substance  and  character  to  provide  the  basis  for  such  a 
modification  and  extension. 
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Introduction 

This  report  lives  a comparison  of  the  language  SPL/I  to  the  Tinman 
lanouage  requirements  (Department  of  Defense  Requirements  for  Hioh  order 
Comrutrr  Proorarminq  Lanuuaqes,  "Tinman"  - 1 March  19 7h,  Section  IV). 
For  the  purposes  of  this  comparison,  SPL/I  is  considered  to  he  defined 
by  : 

SPL/I  Lannuaqe  Reference  Manual  for  Compiler  Release 
A.'J 

Intermetrics,  Inc. 

Cambridge,  Mass. 

July,  1 s 7 6 

Tinman  contains  79  language  renui rements . This  report  compares 
5FL/1  to  each  requirerrert  individually.  If  a requirement  is  totally 
satisfied,  the  accunoanvino  test  is  a summary  of  the  particular 
mechanism  used.  (occasionally  no  text  is  needed  if  a requirement  is 
tot  a 1 1 v satisfied.)  If  a requirement  is  not  totally  satisfied,  the  text 
consists  of  a summary  of  the  shortcomings  and  such  items  as  the  scope  of 
the  changes  necessary  to  fully  meet  the  requirement  and  the  impact  of 
these  changes  on  existing  implementations. 

Each  Tinman  requirement  becins  with  an  introductory  pararranh. 
These  ParaGraphs  are  reproduced  in  this  report.  In  many  cases  they  arc 
followeo  by  several  single-line  summaries  of  features  in  the  area  of  tne 
r coni rement . Usually  those  are  features  which  are  specifically  called 
fnr  in  the  requirement.  A feature  enclosed  in  parentheses,  however,  is 
one  which  the  reviewers  theueht  possibly  desirable,  even  thouqh  rot 
called  for  in  the  requirement. 

Symbols  placed  beside  the  introductory  paragraph  and  the  individual 
features  irdicate  the  deoree  to  which  the  requirement  or  feature  is 
satisfied  by  the  lanquaae.  The  symbols  and  their  meanings  are: 

T - Totally  satisfied 

p - Partially  satisfied 

F - Fails  (not  satisfied  at  all) 

U - unclear  from  the  documentation 

P+  - Almost  totally  satisfied 

P - - only  sliahtlv  satisfied 

n/a  - N-t  applicable  (used  only  tor  individual 
features  when  the  requirement  is  not  satisfies 
at  all> 

(Ihe  symbols  F,  »♦,  and  F-  will  of*en  he  used  with  requirements  vhirh 
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>re  static!  in  one  of  the  forms  "There  will  he  no..."  or  "All...",  oven 
thnu-'t  only  T or  f are  technically  applicable  in  these  cases.) 

The  report  concludes  with  two  summaries.  The  -first  is  of  the 
features  of  $fl/1  which  are  extraneous  to  Tinman  and  the  desirability  of 
retaining  each  of  them.  The  second  is  of  the  lanpuape  as  a whole  and 
the  dtsirabilitv  of  modifying  it  to  bring  in  into  line  with  the  Tinman 
reaui rerents . 
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A1  . The  l.Tn^uaqe  will  he  typ'*d.  The  type  (or  mode)  of  all 
variiiMps,  components  of  composite  data  structures, 
expressions,  operations,  arc!  parameters  will  be  ceterminanle 
at  compile  time  and  unalterable  at  run  time.  The  language 
will  require  that  the  type  of  each  variable  and  component  of 
composite  data  structures  h®  eynliciflv  specified  in  the 
source  programs.  ....T 


The  SPL/I  word  for  "type”  is  "mode".  The  requirement  is  Trt  (see, 
in  particular,  ..  *,L).  The  o ci ** s of  formal  parameters  must  als;,  b® 
ai ven  (i  . 73 > . 


A?.  The  language  will  provide  data  types  for  inteoer,  real 
(floating  point  and  fixed  point),  boolean  and  character  and 
will  provide  arrays  (i.e.,  composite  data  structures  with 
indexable  components  of  homo  :enenus  type)  end  records  (i.e., 
comjnsite  data  structures  with  labeled  components  n* 
hetr rctieoeous  type)  as  tyoe  oenerutorr.  ....  ♦ 

Integer  T 

F l pat i no  Point  I 

Fixed  Point  

boolean  T 

Character  String  f 

Arrays  T 

Records  .................. .........1 


SPL/I  has  all  reauired  types  except  fixed  point;  it  does  hay®  a 
fraction  type  as  a partial  substitute.  The  following  additional  tynes 
nre  provi'-'ec  as  well:  forol®y  ioteqer,  complex  fraction,  complex 
t Imagine  point,  double  precision  integer,  signal,  resources,  process, 
Oit.  (See  pages  49-6R.) 

Adainq  fixeo-nniot  would  be  of  moderate  difficulty.  See  also  the 
comments  under  #5  on  the  character  type. 


A '5 . The  source  (annuane  »ill  require  qlobal  (to  a scone) 
spec i f i cat  ion  of  the  rrerision  for  floatino  mint  arithmetic 
and  will  permit  precision  specification  for  individual 
variables.  This  spec i f i ca t i on  will  be  interpreted  ar  the 
maximum  rrerision  required  by  th*  rrocrrm  Ionic  and  the 
minimum  precision  to  (<■  supported  tv  the  object  code. 
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Global  arithmetic  precision  specification  mandatory  c 

Individual  variable  precision  specification  permitted  f 


T h p precision  of  floatino  point  arithmetic  and  variables  is 
implementation  dependent  Fp.  52). 

* moderate  change  would  he  necessary  to  meet  the  requirement.  Th“ 
chanqc  does  not  strongly  interact  with  other  language  features,  except 
that  a consistent  syntax  should  he  desired  «-o  specify  properties  of 
varieties  of  all  tyres.  Routines  to  perform  the  arithmetic  to  the 
necessary  precision  woulc  be  needed;  note  that  SPL/I  oces  not  even  h.ive 
double  precision  floatim  mint  capabilities. 


A 4 . Fixed  point  numbers  will  be  treated  as  exact  quantities 
which  have  a range  and  a fractional  ster  sire  which  are 
determined  by  the  user  at  compile  time.  Scale  factor 


management  will  he  done  by  the  compiler.  ....f 

Treated  as  exact  ouantitirs  F 

Panne  and  step  size  determined  at  compile  time  .................. F 

Scaling  handled  automatically  f 


SPL/I  has  no  fixed  reint  tyre. 
(Fee  the  comments  on  *2.) 


A5.  Character  sets  will  be  treated  as  any  other  enumeration 
tvre  . 


New  sets  can  be  defined  as  enumeration  types  .................... F 

ASCII  and  EBCDIC  are  provided  f 

(Conversion  capability  between  sets  is  available)  ...............  F 


SPL/I  has  only  one  character  set,  and  the  internal  representation 
is  implementation  dependent.  (p.  53) 

The  necessary  chanoe  is  not  hard;  nor  is  it  trivial.  SPL/1  foes 
not  even  have  an  enumeration  type  Generation  capability,  so  both  this 
and  the  ability  to  define  new  character  sets  would  have  to  be  added 
together.  moreover,  it  would  be  desirable  to  implement  a routine  to 
convert  a character  string  from  one  character  set  to  another. 


SDL/  I 

Rerji r^'ent  A 6 


1 


A * . Tne  l;jnrij?ne  kill  r^djirr  us<*r  sner.i  f icat  icn  of  the 
runter  nf  d.i n.ens i ops , the  nrne  cl  subscript  values  lor  etch 
diversion,  and  tyne  nf  cart  array  n-  onent.  The  number  zi 
ii  me  ns  ions,  t*e  ty;:  e a-ci  the  l»;*pr  subscript  bound  will  he 
He t e r m i nch l e at  cnmoile  time.  The  unoer  suhscrint  bound  will 
he  fPterTirahle  at  entry  to  the  array  allocation  scope. 


vj.jmter  of  dimensions  is  fiyei  at  ccmpile  time  ...................  1 

Tyre  ir  fi*eo  >t  compile  tiT®  T 

Lower  sjhscri;  t hound  is  < ixer  at  co-oil®  time  v 

Uooer  sjpscrir.t  hound  is  fixen  at  scope  entrv  f 

Sue*  cr  irts  orily  irtecers  t r from  tn  erumerat  ior  tyre  ............ 

Sj!  ' cr  i^ts  will  he  from  a contiguous  ranoe  ........I 


The  loner  sutscri~t  hound  is  fixta  by  thf  lannuaoe  definition;  it 
is  always  1 (p.  Ilf.).  Tt  ? upper  subscript  hound  is  fixed  at  compile 
tire  ft.  6 A ) . Furscripts  may  only  be  integers;  SPL/I  has,  no  enumeration 
types  fp.  116).  T h e other  requirements  are  met  (see  p . 6 A - 6 * , 1 1 C - 1 1 ( ) . 

Some  of  the  recuired  rrrrerties  £re  available  by  means  of  array 
slice  references  (p.  1 Ip-121};  usinn  these  to  obtain  variable  ocunds  is 
quite  inefficient,  however. 

Assuming  that  enumeration  types  are  added  in  any  case,  the  chan.,r 
necessary  hr  re  would  he  Toderate.  Fven  allowing  only  the  uroer  found  to 
be  fixer  at  run  time  adds  a level  ot  indirectness  for  references  to  all 
hut  one  dynamic  array  per  scope,  and  interfaces  to  the  dynamic  stack 
allocation  mechanism  would  have  to  be  added. 


»/.  Toe  lanqiiaoe  will  pprmit  records  to  h?ve  alternative 
structures,  each  of  which  is  fixed  at  compile  time.  The  mame 
and  tyre  pf  each  record  compcr.ont  vii  l I be  specified  hy  hhp 


user  ?t  compile  time.  ....f 

Alternative  structures  for  records  are  rnssihle  .................F 

hi s c r i <r i na t i on  condition  may  he  arv  P^rleen  expression  ......  ....* 


S » l / I dues  not  jrevide  for  alterrate  structures  for  records,  which 
are  known  as  ”st r jcturcs"  fr»r>.  62-M)  . 

’h'  necessary  champ  would  ho  rf  easy  to  moderate  difficulty.  com» 
redpS  jrr  of  th®  c statement  ^culd  ‘ «■  required  (or  at  least  hi;hlv 
'esir-t-l?!,  tc  permit  discrimination  based  or  the  structure  --  case 
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labels  are  currently  nn^y  integers.  II  run-time  enforcement  checks  were 
•»«.>rte.-,  ef' re  work  would  he  necessary,  although  SPL/I  Hoes  reruiri  full 
qualification  for  co-ronent  na^es  (o.  12?). 


SPL/I  S 

Regui  recent  PI 


P.1  . Assignment  and  reference  o Deration  will  be  automatica  1 1 y 
defined  for  all  cata  tyrrs  which  do  not  manage  their  -'•ate 
storaoe.  The  assignment  operation  will  permit  any  value  of  a 
given  type  to  be  assigned  to  a variable,  array,  or  record 
comment  of  that  type  or  of  a union  typ°  containing  that 


tyre,  Reference  will  retrieve  the  last  assinned  value.  ....  ’♦ 

Automatically  defined  for  anv  tvne  (except...)  .....P 

Available  for  individual  comprnent*  ............................. T 

(Assignment  and  reference  via  functions)  F 


The  intent  of  the  requirement  is  fully  met  for  all  types  which 
S I L / I has  — it  h?s  no  us°r  defined  tyres  (pp.  157-15?). 

However,  variables  of  certain  types  cannot  be  assigned  to  in  an 
assignment  statement,  for  oooo  reasons  (e.n.,  the  PROOFS'  tyre;  see 
op.  1*5-167) . 

The  only  necessary  chance  is  in  the  wording  cf  the  Tinman 
requirement.  The  intent  cannot  he  to  require  assignment  and  reference 
for  every  type,  for  sene  it  is  net  meaningful  or  not  safe. 


B2.  The  source  language  will  have  a built-in  operation  which 
can  be  used  to  compare  any  two  data  obiects  (regardless  of 
tyne)  for  identity. 


The  ’=•  and  •/=•  operaters  can  he  used  with  any  type.  However, 
noth  operands  must  hr  of  the  same  tyre.  (p.  96-97) 

The  necessary  change  would  he  very  minor. 


Pi.  Relational  operations  wilt  be  automatically  defined  for 


numeric  data  and  all  types  defined  by  enumeration.  ...,P+ 

Built-in  for  all  numeric  and  enumeration  types  .................. 

Ordering  can  be  inhibited  when  desired  ........................ ..T 


Thr  SPl/I  relational  eperaters  are  defined  ter  all  numeric  types; 
the  language  has  no  enumeration  types,  rr  urordered  types  tc  wl'icb 
relational*  can  pp  applied.  (pp.  9 *-*>7) 


p 
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The  only  necessary  channe  is  to  add  enumeration  types;  see  f f> . 


B4.  The  built-in  arithmetic  operations  will  include: 
addition,  subtraction,  multiplication,  division  (with  a real 
result),  exponentiation,  integer  division  (with  inteoer  or 
fixed  point  arguments  and  remainder),  and  negation.  ....t’* 

Addition  T 

Subtraction  ........T 

Multiplication  T 

Division  with  real  result  T 

Exponentiation  T 

Integer  and  fixed  point  division  with  remainder  ...P* 

Neoation  T 


The  remainder  from  an  integer  division  is  not  accessible,  but  there 
is  a *0D  function.  (po.  10P-1H3,  and  Appendix  P,  pp.  P-5  and  n-ft). 

The  result  of  a division  is  of  the  same  type  as  the  operands,  so 
explicit  conversions  are  necessary  to  get  a real  result  from  the 
division  of  one  integer  by  another.  This  is  rot  a violation  cf  the 
Tinman,  but  is  rather  unusual. 

The  necessary  chanre  is  trivial. 


85.  Arithmetic  and  assignment  operations  on  data  which  are 
within  the  range  specifications  of  the  program  will  never 
truncate  the  most  significant  dinit'  of  a numeric  quantity. 
Truncation  and  roundinn  will  always  be  or.  the  least 
significant  digits  and  will  never  be  implicit  for  integers 
and  fixed  point  numbers.  Implicit  rounding  beyond  the 
specified  precision  will  be  allowed  for  floating  point 


numbers.  ....U 

Never  from  the  left  for  data  within  range  ...................... .u 

Never  on  the  rioht  for  integer  and  fixed  noint  .11 

Implicit  floatino  roint  rnundinn  beyond  precision  allowed  .......U 

(Run  time  checks  can  be  avoided)  .u 


Nothing  is  said  abou*  the  ramies  of  results,  or  about  truncation. 
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P6.  The  built-in  Boolean  operation*-  will  include  "and", 
"or",  "not",  and  "xor".  The  operations  "and"  end  "or"  on 


scalars  will  ho  evaluated  in  short  circuit  mode. 

Short-circuit  end  P 

Short-circuit  or  P 

Not  T 

Xor  T 


All  the  reauired  operators  are  present,  but  ANh  and  Op  are  not 
necessarily  evaluated  in  short-circuit  rode.  (pp.  *7-91) 

The  reauired  (and  Questionable)  change  is  of  moderate  difficulty. 
The  rules  for  evaluation  order  in  expressions  would  have  to  be  changed. 


P7.  The  source  lanouane  will  permit  scalar  operations  and 
assifnment  on  conformable  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  lonical 


structure.  ....T 

Scalar  operations  on  arrays  T 


Assignment  between  records  and  arrays  of  conformable  type 


Component  by  component  operations  on  arrays  are  rroviHea 
<cp.  ,»'1-92).  They  pre  apparently  not  provided  for  records  (p.  92). 
Scalars  are  considered  compatible  with  arrays  having  components  of  the 
same  type  (p.  102),  and  scalar  actual  parameters  are  even  comratible 
with  array  formal  parameters  (p.  PH). 

Assignment  also  meets  the  reouiremeot  (pp.  157-15P). 


btf . There  will  be  no  implicit  type  conversions  but  no 
conversion  operation  will  le  required  when  the  type  of  an 
actual  parameter  is  a constituent  of  a union  type  which  is 
the  formal  oarameter.  The  hnauaae  will  orovide  explicit 
conversion  operations  amonn  integer,  fixed  point  and  floating 
point  data,  between  the  object  representation  of  numbers  and 
their  representations  as  characters,  and  tetweer  fixed  point 
scale  factors.  ....j 
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No  implicit  conversions  T 

Fxrlicit  between  inteqer,  fixed  point,  anti  f l oat  i no  point  .......P 

Exolicit  between  fixed  point  scale  factors  F 

(Explicit  between  inteqer  and  Boolean)  T 

(Fxrlicit  between  inteoer  and  enumerated  types)  ................. f 

(Explicit  between  different  enumerated  types)  F 


SPL/ 1 has  no  fixed  point.  However,  conversions  tetween  integer  and 
floatino  point,  and  floatinc  point  and  fraction,  are  provided, 
(pp.  B -22  through  B-24).  Many  other  explicit  conversions  are  also 
provided,  including  between  Ell  and  Boolean,  and  PIT  and  integer,  and 
character  string  and  inteoer,  floatino  point,  and  fraction  (pp.  B-22 
throuoh  P-32). 

There  are  no  implicit  conversions  - not  even  mixed  mode  arithmetic 
(pp.  8 2-103). 

The  necessarv  change  is  to  add  fixed  point,  see  A2. 


B9.  Explicit  conversion  operations  will  not  be  required 
between  numerical  ranges.  There  will  be  a run  time  exception 


condition  when  any  integer  or  fixed  point  value  is 
truncated.  ....p- 

Implicit  conversion  between  ranges  ........F 

Exception  condition  on  integer  and  fixed  point  truncation  P 


The  only  instance  of  range  in  the  language  is  inteqer  and  double 
precision  integer,  and  as  these  are  considered  different  types,  explicit 
conversion  is  required  (r.  IP?). 

Run-time  exception  conditions  on  truncation  are  mentioned  only  for 
STRING  and  BIT  assiqnrent  (c.  15*). 

Providing  for  run-time  exception  conditions  on  truncation  would  be 
of  moderate  to  high  difficulty;  the  language  has  no  mechanisms  in  this 
area  at  all. 

Adding  ranges  (and  implicit  conversions)  would  be  of  moderate 
difficulty. 


P 1 Cl . The  base  lannuaqe  will  provide  operations  allowino 


L — t 
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pr-orams  to  interact  kith  files,  channels,  or  devices, 
includino  terminals.  These  operations  will  permit  send  inn 
anJ  receivin'!  bott  rieta  and  control  i n t ormat i on , will  enable 
pronrams  to  dynamically  essirr  and  re-.ssinn  1/0  devices,  will 
provide  user  control  for  exception  ronaitions,  and  will  not 
he  installation  der  tni»rt.  ....P 

Sr  no  ire  and  receiving  of  o?.ta ....T 

sordino  and  receiving  of  control  information  .................... t 

Dynamic  device  assignment  F 

User  exception  condition  control  F 

I ns  tat  lotion  independence  .................................. .....r 

(beta  formatting  caps l i l i t y ) ...F 

(Reading  and  writing  of  tit  stripes)  T 

There  are  only  six  I/n  r roernurps  in  SPL/I:  CPFh,  CLOSF,  PUT,  f.ri, 

■J  R I T F L 1 ► F , and  RFAt’LIKT.  They  operate  with  virtual  charrels,  and  are 
installation  and  device  Dependent  . tvnaTic  device  resssi  inrer*  is  not 
provided.  (no.  r--t6  thrmnh  F-21) 

Just  what  the  T inrun  requires  is  not  at  all  clear  enough  in  detail 
tc.  determine  whether  the  necessary  cranoes  are  fairly  easy  or  moderately 
difficult. 


Ml.  The  len"uaae  will  provide  orerrtions  on  data  tyres 
defined  as  power  sets  of  enumeration  types  (see  F6).  Tn»*se 
operations  will  include  union,  intersection,  difference, 
cor  le^cot,  ar^  an  clement  eradicate.  ....( 

linior  T 

Intersection  T 

ri  Mrrcnce  F 

C o ’ i te-enf  T 

"enters hirj  predicate  t. ........ ..F 

(Set  inclusion)  F 

SF'l/1  F ■;  no  po**rsets,  tut  some  of  the  reruired  operations  are 

rrnvi^ed  on  nit  strincr,  wMc*  are  in  effect  powtrset*"  .here  the 

• ts  are  unknown  to  the  compiler.  (op.  cp-95) 

It  »ouM  te  easy  to  add  a differer.ee  operation.  Addirn  a 

• •vrr.M'  onfr-'tio1  would  reo'iire  also  addinu  pcK**rset  s , vhirh  would 

• w»  • itor**  work  (hut  less  ♦tor  addiro  fixed  ooint,  for  example). 
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Cl.  Side  effects  which  are  rte;>?rlpn*  on  the  evaluation  orrer 
am nr'*  the  arguments  of  an  ?»r  res'ior.  will  be  evaluated 


I ef ♦ -to-ri nht . ....* 

Side  effects  must  recur  in  let  t-to-r  v'ht  order  ..................  f 

(Fmbedded  ass  i inments  ) F 


The  SPL/I  rule  is  that  the  order  of  evaluation  of  operands  of  a 
sincle  infix  ooer.'tor  is  undefined.  This  is  a ouch  better  rule  than  th* 
Tinman  requirement,  tut  it  ^rcs  not  me«*r  the  requirement.  (p.  77) 

The  ch'nr,e  is  '*nder*telv  difficult.  It  »ould  have  a r^aicr  effect 
nr  enqe  it  ne  ration  in  the  ccmriler,  and  would  leao  to  worse  ende  in  a 
ij-nher  rf  cases. 


C7.  Which  parts  of  an  expression  constitute  the  operands  to 
each  eperation  within  that  expression  should  fce  obvious  to 
the  reader.  There  will  be  few  levels  of  operator  hierarchy 


and  they  will  he  widely  recoqri rcu . ....ft 

few  precedence  levels  T 

ho  use  r-cie  f ir  ed  precedence  levels  .................I 

Operands  of  an  operation  are  obvious  ..f’ 


There  are  nine  precedence  levels,  which  seems  reasonable  (p.  hS). 
There  is  no  way  to  define  re*  operators,  much  less  new  precedence. 

Operands  of  an  eperatien  are  usuallv  ot)vious,  tut  A/P*C  anr-  */o/c 
are  permitted  (p.  1(!b). 

risallowinc  the  two  noted  cases  chould  be  relatively  easy. 


T3.  Txpressinns  of  a niven  type  will  he  uerritted  anywhere 
in  source  rreersns  where  h.cth  constants  and  references  tc 
variables  if  that  type  are  alloweH.  ....T 


fully  mPt  (pp.  *>7-1  ?v) 
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C A . Constant  expressions  will 
anywhere  constants  are  allowed,  and 
oe  evaluat®^  hetor®  run  time. 


1 t 


be  allowed  in  proqrams 
constant  expressions  will 


I m a few  conte»ts,  only  integer  literals  are  allowed  --  for 
example,  the  renetiticn  factor  within  a structured  constant  (i  . Ill), 
and  the  l.oels  on  parts  of  a case  statement  (r-  135).  Array  upper 
orunds  can  however  be  expressions,  evaluable  »t  compile  time  (p.  6A). 

The  required  chrnce  would  Le  fairly  easy,  although  sore  cjre  would 
be  necessary  to  avoid  syntactic  amhinintv. 


Cr) . There  will  he  a ronsistert  sr^  of  rules  applicable  to 
all  oarameters,  whether  They  be  for  procedures,  for  types, 
for  exception  hardline,  for  parallel  processes,  for 
declarations,  or  for  ruilt-in  or  or; tors.  There  will  be  no 
special  operations  (e.n.,  array  subs t ruct ur i no)  applicable 
only  to  parameters.  Uniformity  and  consistency  contribute  to 
ease  of  learnino.  ...,T 

Parameter  rules  consistent  in  all  contexts  ........T 

Mo  special  operation?  e'plicafle  only  to  parameters  ....r 

SPL/I  really  uses  oarameters  only  for  procedure  calls.,  so  the 


hucstior  of  consistency  dons  rot  arise.  Sorer. ver,  a orocer?ure  name 
cannot  le  passed  as  a parameter  <ri  . 51,  6 7,  ?*: , ISA),  sc  no  additional 
ways  of  hindina  arise  f nr  oaramet®rs. 


C6 . Formal  and  actual  parameters  will  always  "(tree  in  tyre. 

The  njmoer  of  dimensions  lor  array  parameters  will  be 
determinable  at  co^nile  time.  The  size  and  subscriDt  ramie 
for  array  oarameters  need  not  be  determinable  at  compile 
time,  I ut  can  oe  passed  as  part  of  the  parameter.  ,...ut 

Actual  and  formal  parameters  will  aoree  in  type  ...........I 

Rank  of  oarampter  arrays  is  fixed  at  cc'rilr  time  T 

Parameter  array  ri7t  and  subscript  ranee  can  he  parsed  .......... 


Thc  only  violation  is 
as  they  are  fixed  ft  1 h y 
array  slice  (pp.  11R-1P1) 
capability. 


p asse  1, 
that  an 
c f the 


•>  n / 1 


U 


Rin-Jin’  of  f-rmal  to  actual  r arum^t  pr  s is  discusred  on  pp.  79-M  . 

Ttf  necessary  c^antjp  is  rnrt  of  the  work  of  adainn  lower  oojnds 
other  than  1;  see  the  comments  or  recui  rerrent  Ah. 


C?.  There  will  he  only  four  classes  of  formal  parameters, 
for  data  there  will  he  these  which  act  as  constants 
rer  rest ntiro  the  actual  parameter  value  at  the  time  of  call, 
aoH  tt'Ose  which  rename  the  actual  parameter  which  must  be  a 
variable.  In  addition,  thrr®  » i I l ke  a formal  parameter 
class  for  specifying  the  control  action  when  exception 
conditions  occur  and  a class  for  r roerdure  parameters. 


Act  as  constants  (call  bv  value  plus)  ...........................  I 

Act  as  variables  (call  b>  reference)  ........................  ,...T 

Fxception  control  I 

Procedure  parameters  f 

(Art  as  variables,  but  call  hy  value)  1 

(Act  as  variables,  result  parameter)  F 


r'Oth  VALUF  and  IN'FllT  parameters  are  provided.  The  first  is  the 
same  as  Alnol  60  (the  actual  parameter  does  not  change,  but  th**  formal 
parameter  may);  the  second  is  the  corstant  parameter  called  for  in  the 
Tinman.  Call  by  reference  (renaminn)  parameters  are  called  Ih'OUT. 

There  are  no  special  provisions  for  exception  control  parameters, 
and  procedure  names  cannot  he  parameters.  (pp.  51,  67,  79-61,  ISA). 

The  required  extensions  would  le  moderately  difficult,  .it,  'ut  the 
same  amount  of  work  as  adding  "numeration  types.  The  missing  features 
do  not  interact  sfronoly  with  other  l anting ge  features. 


CP.  Specification  of  the  tvje,  ranne,  orecisicn,  dimension, 
scale,  and  format  of  parameters  will  he  optional  in  the 
"rnrHuro  declaration.  More  r ♦ them  will  he  alterable  at  run 


tic".  . . . . f 

Above  properties  optional  P- 

Above  properties  are  fixed  at  run  tim»  F 


tverythino  that  can  be  specified  about  a formal  parameter  --  i.o., 
its  more  and  si7e  — tust  t:  e specified.  (rp.  6 7,  79).  The  concept  of 
leneric  proceoures  i*  net  in  the  lanruaoe. 
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Nr  te  that  i 1 an  array  is  passed  through  tvc  levels  of  r roce dures , 
its  size  "ust  be  competed  to  the  array  at  each  level,  even  if  the  irr  iy 
is  referenced  only  as  an  actual  parameter  at  that  level. 

Tie  addition  of  generic  procedures  v.ou  l d be  fairly  hard, 

particularly  i 4 efficient  code  is  desired. 


f°.  Tnere  *ill  be  provision  for  variable  numbers  of 
nr<Hi»-erts,  but  in  such  cases  all  hut  a constant  number  of 
the"  must  he  nf  the  sane  type.  Whether  a routine  can  have  a 
variable  number  of  armiments  must  he  determinable  from  it? 
description  and  the  r. umber  of  jrnenents  for  any  call  will  tc 
determinable  at  cenrile  time. 

Variable  number  of  armiments  possible  p- 

a l l tut  a constant  number  of  arguments  have  the  same  type  .......F 

Number  of  arqu-’cnts  in  each  call  is  Fixed  :»t  compile  time  T 

''nly  the  built-in  OFT  and  F'UT  I/O  procedures  accent  a variable 
number  of  arguments,  and  notMnr  ij  said  about  tyre.  fpp.  7 9-81, 
Append i y I > 

Tr.t  chanue  ^cula  be  at  least  moderately  difficult. 
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D1  . The  user  >.  i 1 1 have  the  ability  to  associate  constant 
va  li.es  of  any  type  with  identifiers.  ...,F 

There  is  no  „ay  to  associate  an  identifier  with  a constant  in 
SPL/T.  (n.  49) 

The  reouiref  change  is  trivial. 


D?.  The  language  will  provide  a syntax  and  a consistent 
interpretation  for  constants  of  built-in  data  types.  'Himpric 
constants  will  have  the  same  value  (within  the  specifier; 


precision)  in  loth  programs  and  data  (inrut  or  output).  . . . . u + 

Literals  for  all  tuilt-in  types  ..T 

Consistent  interpretation  in  program  ana  data  .u 


Literals  are  provided  not  only  for  rill  huilt-in  uata  tynes,  hut  for 
generated  types  fe.y.,  arrays,  records)  as  <n  l l , in  a wav  which  is  easy 
to  read.  (r  a.  IdC-ll?) 

vothinq  is  s=>id  about  consistency  of  interpretation  fur  programs 
and  data,  hut  since  precision  is  i "*o  Itment  at  i on  dependent  (p.  b?)  , we 
doutt  that  the  requirement  would  he  net  by  cross-compilers. 

rrcvic,inn  I'recisicn  in  a tnach  inrt  inrieper'dent  way  wouM  oe 
moderately  difficult.  see  also  M. 


05.  The  lanouape  will  permit  the  user  to  specify  the  initial 
values  o*  individual  variables  as  rart  cf  fheir  declaration. 
Such  variables  will  or  initialized  it  the  time  of  their 
apparent  allocation  (i.e.,  at  rntrv  to  allocation  scone). 


There  will  be  no  default  initial  values.  ....«>♦ 

Initial  value  can  be  specified  as  rart  of  the  declaration  .T 

Initialization  occurs  at  allocation  scope  entry  T 

No  default  initial  values  J 


The  requirement  is  probably  fully  rr.et,  but  nothing  is  said  about 
default  initial  valurs,  and  reference  to  a variable  without  a value  is 
apparently  not  detected  at  run  tiee.  (f.ee  rr.  69-71,  114-175.) 
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DA.  The  source  larouace  will  r°ouire  its  users  to  scecify 
i n.ii  vi  oua  l ly  the  range  of  all  numeric  variables  and  the  step 
sire  t'-r  fixer  point  variables.  The  range  specifications 
..ill  r«  interpreted  as  the  mavimal  range  of  values  which  will 
be  assigned  to  a variable  and  the  minimal  ranne  which  must  Ke 


surtnrteH  by  the  obiect  eerie.  Panae  and  ster  siz«* 

set ci f i cat  ions  w»ll  not  te  internretea  as  defining  new 
ty'es.  . . . . F 

Numeric  variable  ranne  specification  mandatory  ............... ...F 

Fixed  point  variable  steo  si/e  ?•:  eci  f ication  iranrietery  ..........F 


and  stAr  si/A  S”e  c i * i ca  t i nnc  Ho  rot  ~efire  a new  tyoo  .....F 


SFI./T  has  no  way  to  declare  range  or  ster  size,  and  -ir.tncer  and 
•ioubl®  precision  i^f ener  are  treated  as  two  different  types,  with 
explicit  conversion  necessary  to  assign  one  to  the  other.  (Srr  variable 
declarations,  op.  67-71;  pr’l,'’tive  modes,  r>r  . 51-3A;  and  assignment, 
no.  1 7-1  5°  ) . 

The  necessary  chance  is  moderately  Hi f f i cn  It  . The  syntax  needs  to 
be  changed  to  allow  for  ranee  and  sten  size  aec  larations,  and 
romp i l »-t i me  and  run-time  checks  must  fp  implemented.  There  is  a strona 
teroction  between  this  nrd  the  addition  of  fixed  point. 


hi.  The  ranne  of 
variable,  arr?y, 
t vpe , any  defined 
enumeration  ty^e. 


values  which  can  If 
or  record  c omnone n*  , 
tyre,  or  a continuous 


. s s oc i a t ed 
will  be  ary 
subsequence 


w i t n a 
bui It -in 
of  ;>nv 


..r-f 


Ranees  of  an  '•numeration  tyre  are  allowed  ...........r 

No  arbitrary  restrictions  on  the  structure  of  data  .............. t 


There  ■•re  no  cnum.eratior  tyres,  croc  no  ranges  thereof  (rp.  A9-6S). 

T*-erp  are  no  arbitrary  restrictions  on  the  structur*  of  data; 
records  can  be  components  of  arrays  and  vice  versa  (rp.  A9,  fv-nc).  It 
is  st?tfd  on  naoe  117  that  an  arrsv  elemort  is  a scalar,  but  this  is 
clearly  a simple  wording  error  ir  tFe  manual. 

' ncr  coum.er  a*  ion  tyi  es  ore  roderi  Fsee  F6),  and  integer  ranges  are 
added  (sec  PA),  umviriino  ranees  cf  enumeratinn  tynes  would  ^e  trivial. 
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Of).  The  lannuane  will  provide  a printer  mechani  cn.  which  can 
be  used  to  build  data  with  shared  and/or  recursive 
substructure.  The  pointer  prooerty  will  onlv  attect  the  use 
of  variables  fincludino  array  and  record  components ) of  sore 
data  types.  Pointer  variables  will  be  as  sate  in  their  use 
as  are  any  other  variables. 


Recursive  an c network  structures  provided  .....T 

bandies  va r iab le-va I ue  and  structure-component  connections  r 

noirter  property  is  an  attritute  of  a typeo  variable  l 

Pointer  property  net  for  constants,  affects  only  asnonment  . . . . . H 
Pointer  property  mandatory  tor  dynamic  allocation  ............... N / * 

Allocation  scone  rover  wider  than  access  scope  .........I 

(Fibber  the  value  or  tie  pointer  ir  modifiable)  1 

(Pointer  mechanism  handles  nrocedures  and  parameters)  ...........F 

(Rene  and  replace  assignment-  have  different  syntaxes)  1 

(built-in  dynamic  variable  creatior)  ....I 

(VariaDle  ecuivalence  classes  are  declarable)  * 


FPL/T's  pointer  mechanism  is  almost  identical  to  that  of  Pascal;  in 
other  words,  it  is  a c;ooo  me.  POINT!  p is  a medr  , but  pointer  values 
are  not  directly  accessible.  A rointrr  variable  roirts  to  an  oticct  of 
a specified  type.  Fither  the  nointec  or  the  pcinted-tc  value  can  be 
assimer!  to.  The  latter  is  referercen  as,  e.o.,  p?  (similar  to  ''tscal's 
p“).  A pointer  c=n  share  its  nnirteb-to  value  only  with  another  point?*- 
variable.  A heap  allocation  mechanism  is  provirec.  (rp.  *>?-S1, 
1?b-1?0,  "-ID,  P-11) 

To  charge  SPL/I's  pointer  mechanism  to  meet  the  Tinman  requirement 
would  te  a lot  of  work.  vuct  of  tte  work  would  be  in  defininn  the 
requi r rnent  itself  tn  be  a viable,  sensik  le  one,  in  more  detail  than  at 
present  . 
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C1  . The  user  of  tie  lanauaoe  will  be  able  to  define  new  data 
types  ml  operations  within  rro-Jrans.  ....P- 


n.  special  rrech  anisms  art  provided  for  defining  ntw  types. 

HOwevsr,  arrays  arc  records  are  provided  as  type  qrnerators,  and  own 

variatles  (called  STATIC)  would  allow  one  to  aefine  ?rd  use  a new  type 

via  "mredure  cell*-,  with  the  components  of  the  ciita  objects 

i nacc’  ssi*  I e except  via  the  (.  rnreclures.  This  provides  rrucl:  of  the 

recuired  capability,  albeit  inefficiently,  even  thcuoh  the  methods  are 
perhaps  different  free  those  ervisicreo  by  the  Tinmer. 

Ad-iitinn  of  e srecial  purpose  abstract  type  mechanism  would  be  a 
major  r if  nr t . 


Ti.  The  "use"  of  defined  types  will  be  indistinguishable 
from  tui It -in  types.  . ...F 


See  the  torrents  or  requirement  FI. 


£3.  FnCh  nroqram  comnorert  will  he  defined  in  the  base 
lanuua-'e,  in  a library,  or  in  the  nr  car  am.  There  will  be  no 
default  declarations.  . . . . T 


fully  met  (see  pp.  36-4P). 


F4.  The  user  will  fe  able,  within  the  source  language,  to 
extern  existino  operators  to  new  beta  types.  ....F 


See  the  comments  on  renuirenr»rt  ri. 


ft-.  T ypp  definitions  in  the  source  lanouacje  will  permit 
definition  of  both  the  class  of  dat*  ofiects  ermprisino  the 
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tyre  rnd  the  s*t  of  operations  applicable  tc  that  class.  A 
defined  tvre  will  not  automatically  inherit  the  operation*-  of 
the  data  with  which  it  is  represented.  ...,p- 

fonstruction  T 

Selection  I 

Predicates  ....r 

Type  conversions  T 

Operations  and  data  can  be  defined  tojether  ....P 


The  only  »ay  to  define  operations  on  new  types  is  by  procedures. 
This  allo.s  construction  end  type  conversion  operations,  with  a notation 
much  like  that  for  built-in  tyres.  It  does  net  allow  the  definition  of 
infix  rreaicate  ooeratrrs,  or  of  selection  operators  which  can  appear  on 
the  left  rand  side  of  an  assianrent  statement. 

See  the  comments  on  reouirement  11;  a major  change  would  be 
rer.ui  red. 


tc.  TTe  data  rbjects  comprising  a defined  type  will  be 
definable  by  enumeration  of  their  literal  names,  as  Cartesian 
products  of  existing  tyres  fi.e.,  as  array  and  record 
classes),  by  discriminated  union  < i . e _ , as  the  union  of 
disjoint  tyres)  ar.d  as  the  po,er  set  r.f  an  enumeration  tyoe. 
There  definition*  will  be  processed  entirely  at  comilc 
time. 


fc  numeration  . . F 

Cartesian  products  (records)  T 

Discriminated  union  F 

Fowerset  of  an  enumeration  tyre  I 


Only  printers,  records,  and  arrays  are  provided  as  typ*  generators, 

(rr.  5*-* 6) 

< moderate  chance  would  he  required.  Adoinc  enumeration  types  and 
powersits  wopM  not  be  too  her*1;  most  powerset  ooerators  are  already 
provided  (see  n-11).  Addinc  discriminated  union  would  be  somewhat 
nar^er,  as  it  would  affect  the  syntax  and  semantics  of  Tore  statement* 
Ce.g.,  case). 


r l . 


Type  definitions  by 


free  urion 


(i 


.e ., 


union  of 
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non-disjnint  tyre*-)  and  suhsettino  are  not  desired. 

r.n  I v roint'TS/  records  end  srra>s  are  provided  as  type  jenerators. 
(fa.  t>r-6r) 


ty  . v»er  detinini;  a type,  the  user  i 1 1 he  able  to  specify 
the  initialization  end  finalization  procedures  for  the  tyre 
and  the  actions  to  he  taken  at  t hr  time  of  allocation  enfi 
dfs|  location  of  variables  rf  ♦-hat  type.  . ...r- 

Initialization  ' 

Finalization  f 

All r cation  actions  I 

Deallocation  actions  ....( 

Allocation  could  be  defined  as  a procedure,  usino  either  a larj? 
pre-declared  array  or  heap  storaoe  vie  pointers.  Initialization  cjiiM 
also  h®  defined  os  a procedure,  but  with  a notation  r ons i uerab l y 
different  from  that  for  built-in  types.  Finalization  and  deallocation 
cannot  be  defined  in  a sensit  le  >•  ay,  because  there  is  no  ^ay  for  a 
procedure  to  autorat ical ly  net  control  at  exit  from  a scope. 

See  the  comments  on  require 'rent  11. 
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M . The  lamuare  will  allow  the  user  to  distinouish  between 
scrpp  cf  allocatin''  and  scope  of  sccfs.  ....P 


allocation  and  access  scope  can  he  different,  but  only  if  the 
allocation  scone  is  the  whole  proqran,  as  in  Alaol  A'1  or  CS-4 
(pp.  AV-7 1). 

fhc  chanoe  is  fairly  easy.  Tne  AUTOMATIC  storage  class  declaration 
would  reed  an  '■•ptional  parameter,  niving  the  block  o.ine  of  the 
allocation  scope  block. 


r?.  Tie  ability  to  limit  the  access  to  separately  defir.eu 
structures  will  be  availahle  both  where  the  structure  is 
defined  and  where  it  is  used.  it  -'ill  he  possible  to 
associate  nev  local  names  with  separately  defined  oroqram 


component  s . 

Allowable  operations  can  he  limited  T 

Access  can  be  limited  where  used  1 

Txternal  declarations  reed  not  all  have  the  same  scope  ..........r 

Na"<ino  conflicts  can  be  avoided  C rena^inq)  ..F 


Access  can  be  limited  wher®  a structure  is  used  by  only  declaring 
as  EXTfPNAL  the  desired  structures.  There  is,  however,  only  a sinile 
external  scope  (RIOPAL  on  definition,  FXTERhAL  on  reference).  Allowable 
operations  can  be  limited  hy  making  the  data  ohiects  own  (STATIC)  »ithin 
a procedure  definino  the  operations.  There  are  no  re-namino  provisions. 
Cap.  6<?-71) 


Satis^yinq  the  requirement  with  a special  purpose  "cluster’' 
mechanism  would  he  a fairly  major  chanqe,  closely  connected’  to  that 
required  tv  El. 


F 3 . The  scope  of  identifiers  will  be  wholly  determined  at 
con" i l e time. 


Fully  met  fpr.  3<S-4'J) 
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F 4.  A variety  of  apr  l i c at  i on-nr  i rrte'i  data  and  operations 
• ill  te  available  in  libraries  and  ersily  accessible  in  tfie 

lancua-j  > • ....f 


Th®  run-time  support  library  contains  no  such  procedure  (fprendiv 


ncr  abstract  tyres  are  .dded  ( r enii i r emer t FI),  tbrn  meet i re  this 
r equi  re*rent  could  mean  cnly  a little  work  cr  a tremendous  amount, 
depending  on  the  size  of  the  desireo  library. 


F5.  bronran  components  net  defined  within  the  current 
pro. rai  and  not  in  the  hasp  lanrua,e  will  be  maintained  in 
co''i~ile  tine  accessible  libraries.  the  libraries  will  if 
capable  of  hrldino  anvtbim  definable  in  the  lancuacjc  i.no 
will  net  exclude  routines  whose  bodies  are  written  in  other 
source  languages.  . ...P- 

Prnnran  component  libraries  accessible  at  compile  time  F 

Libraries  can  contain  foreign  language  routines  r 

lnttrfe.ee  retirements  checkable  at  crrrnit®  time  ..T 


comp i l r-time  libraries  are  not  mentioned  in  the  Refererce  Manual. 
It  is,  however,  possible  to  declare  the  properties  of  separate 
conri l aticn  modules.  (pp.  33-35) 

the  necessary  chances  are  at  least  •’Oderate  in  scope. 


Fb.  Libraries  and  Comports  will  be  indistinguishable.  b<>y 
.nil  he  capable  of  holriim  anything  definable  in  th® 
larua’e,  and  it  ►ill  ce  possible  to  *ssociate  then  with  any 
le'/el  of  pr  on  r ammi  nn  activity  from  systems  throtnh  project1 
to  irdividual  nrorrarris.  There  *ill  be  nary  specialized 
co"pools  or  libraries  any  user  specified  subset  of  which  is 


immediately  accessiDle  from  a giver.  program.  . . . . l> 

libraries  »rd  compocls  ».  i 1 1 If  ipdist inouishsble  ......  i 

Immediately  accessible  suhlihrarics  ?•  t any  level  > 


T> ®re  is  nr  mention  of  library  mechanisms  in  the  Reference  ranual. 
(The  requirement  is  rot  really  a language  regui rement ) . 
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f~>.  The  source  larouaoe  will  contain  standard  machine 
independent  interlaces  to  "acnine  dependent  capabilities, 
includin'’  terinheral  equipment  and  special  hardware.  ....F 


nhilr  the  multiprocessing  and  si  one l lino  statements  (op.  15P-19M 
might  le  usable  to  partly  meet  this  reau i rent nt , their  connection  to 
real  h?rdvare  is  implementation  dependent  Ip.  1 hs?). 


The 
s c op  e c f 


requirement  is  so  vague 
the  recc'sary  chance. 


that 


it  is  i rr.p cssihle  to 


estimate 


the 
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ri.  The  language  hill  provide  structured  control  mechanisms 
for  sequential,  conditional,  iterative,  ano  recursive 
control.  It  will  also  provide  control  structures  for 

(rseudo)  parallel  orocessinn,  exception  handlir.q,  ano 

asynchronous  interrupt  handling.  ....Pt 

Sequential  execution  .T 

Conditional  execution  T 

Iteration  ...T 

Recursion  T 

(Pseuc o')  parallel  rrocessinq  ........................ ............T 

Txcertion  hand l i nr  ...P- 

* s y r ch  ror.ous  interrupt  haridlinc  .................................  P— 

Control  structures  from  a small  set  o4  simple  primitives  ........T 


chile  the  parallel  processing  facilities  of  the  lanouaoe  could 
presumably  be  made  to  handle  interrupts,  the  association  of  hardware 
siqnals  with  softvarr  signal  variables  is  not  part  of  the  laoquage 
definition  (p.  1*6).  (The  language  does  specify  & syntax  for 
association  both  hardware  and  software  signals  with  signal  variables, 
but  the  semantics  of  the  associaticr  are  imp lementat ion-dependent .) 

There  are  no  mechanisms  for  handlinn  specific  exceptions  (the  same 
imr ler entation-de; ennent  technicue  mentioned  in  the  previous  paragraph 
is  available,  hut  each  implementation  will  specify  which  exceptions  can 
be  handled),  and  neither  a label  nor  a procedure  rame  can  be  rassed  as  a 
parameter  (op.  9D-104,  124,  1?6,  I'**). 

Control  structures  are  described  in  pp.  131-196. 

fnlv  a moderate  change  woulo  be  required.  *uch  of  the  necessary 
mechanism  is  already  present  in  the  parallel  processing  facilities. 


G?.  The  source  language  will  provide  a "GO  TO"  operation 
applicable  to  rrocram  labels  within  its  most  local  scope  of 
del irition.  ....1 


Fully  met.  fp.  1*56) 

white  thr  re  gui  rem.ent  is  met,  the  restrictions  on  GOTO  and  on 
FNPLOOr  , r X I T , and  FhPITFPATJCN  stat**m*nts  will  lead  to  very  awkward 
oroaramm irg  in  some  cases.  Fop  rxemrle,  INDLOOP  cannot  lead  to  outsi  1c 
of  a lfrlx  block  in  the  iteration  statement;  TXIT  muse  he  used  (and  in 
most  cis*s,  f NO in dp  later).  (ro.  147-150) 
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An  unrestri cted  GOTO,  used  carefully,  would  lead  to  more  readable, 
nr?  efficient  programs. 


G3  . The  conditional  control  structures  will  be  fully 
nartitioned  and  will  permit  selection  aronc  alternative 
con.p  ut  at  ions  based  on  the  value  of  a eoolean  expression,  on 
the  subtype  of  a value  from  a discriminated  union,  or  on  a 
computed  choice  amono  labeled  alternatives.  ,...P+ 

Rased  on  Poolean  expression  I 

Rased  on  type  from  di scriminated  union  ..........................  F 

Rase*  on  computed  choice  amono  labeled  alternatives  ..r 

All  alternative  must  be  accounted  for  T 

Si'-blr  nechanisms  will  Le  supplied  for  common  cases  ............. T 

The  conditional  control  structures  are  I F . . . THEN . . . FLSF  . . . F Nb I F and 
DO  CASF...OF...CFLSF...ENDCASF  <r c.  136-139).  They  meet  *hr 
requirements  exceot  in  relation  to  discriminated  union,  which  the 
taniuane  does  not  have. 


''nee  discriminated  unicr  is  added,  providing  conditional  control 
structures  based  on  it  will  he  easy. 


G4.  The  iterative  control  structure  will  permit  the 
termination  conditior  to  appear  anywhere  in  th®  loon,  will 
require  control  variables  to  be  local  to  the  iterative 
control,  will  allow  entrv  only  at  the  head  of  the  loop,  and 
will  not  impcsp  excessive  overhead  in  clarity  or  run  the 
execution  costs  for  common  special  case  termination 
conditions  (e.a.,  fixed  number  of  iterations  or  elements  of 


an  array  exhausted). 

Termini<tion  can  occur  anywherr  in  the  loon  T 

Multiple  terminatinn  predicates  are  possible  ....................  T 

Fntry  permitted  only  at  the  loop  head  T 

simple  cases  are  clear  and  efficient  ........................... .P 

Control  variable  is  local  to  the  loop  F 


Control  value  is  efficiently  available  after  termination 


SPl/I  has  fairly  cl®an  iterative  statements:  WHILE,  UNTIL,  and  FOR 
(cc.  14U-14*).  The  control  expressions  for  the  FOR  are  evaluated  at  the 
start;  better  efficiency  miesht  result  f rom  a restriction  ar.iinst 
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modif/inr  their  values  in  the  Inop  . The  value  o f toe  control  variable 
is  - I wavs  available  on  loon  termination,  so  it.  is  rot  local  to  the  loop, 
and  this  will  not  be  efficient  in  alt  cases  (e.q.,  where  the  user  didn't 
ni>p  l the  value).  Another  F o p inefficiency  is  mentioned  under  Jl. 

The  necessary  chames  are  st  rai  ot  tf  c.rwa rd,  and  would  rrobatly  be 
fairly  easy,  but  not  trivial,  to  moke. 


GS-  Recursive  as  well  as  rcnrecursi ve  routines  will  ^e 
available  in  the  source  lentuio^e.  It  will  not  he  possible  to 


define  procedures  within  the  body  of  a recursive 
procedure.  . . - . F 

No  recursive  procedures  within  recursive  procedures  ......... . . . . f 

(Maximum  depth  of  recursion  can  be  specified)  ...................  F 

( Rectrs  iveness  must  be  specified)  ......n 


There  is  no  restriction  aciainst  nestino  of  recursive  procedures 
(np.  7*>-f 7 , 41-4  4).  1 t is  rossihle  to  declare  a procedure  tn  he 
NONk'Ef  N1PANT,  which  can  nreatly  increase  efficiency. 

tHcinn  the  restriction  would  *-p  trivial;  chanqinq  the  cccile'*  to 
take  cidvantaje  rf  the  extra  informatics  to  rrcduce  core  efficient  code 
woulo  probably  be  somewhat  harder. 


G6.  T*e  source  lannuape  witl  provide  a parallel  procession 
cap ah l it y.  This  capability  shoulo  include  the  ability  to 
create  and  terminate  (pcssitle  pseudo)  parallel  processes  and 
for  these  urocess°s  to  oain  exclusive  use  of  resources  durino 
specified  portions  of  their  execution. 


Able  to  create  and  terminate  parallel  processes  ................. T 

Process  can  qain  exclusive  use  nf  resources  ......... ............T 

No  parallel  routines  within  recursive  routines  ....T 

No  routines  within  parallel  routines  F 

Maximum  number  of  simultaneous  instances  are  declarable  F 

(Access  rules  are  enforced)  ..................................... F 


Parallel  procession  facilities  are  described  on  pp.  1S9-196;  they 
pooeae  overl)  complex  f?r  the  capability  provided,  and  they  clearly 
depend  cn  an  (expensive)  hear  storaqe  mechanism.  A parallel  module  must 
he  a program  d»c  laratio’"  (o.  ■’rr’),  which  cfnnot  be  contained  witnin  -i 
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procedure  declaration,  tut  can  contain  another  pronram  declaration 
(no.  74-7S) . 

*eetino  the  letter  of  the  req.ii  recent  would  not  he  hard.  Changinq 
the  mechanism  to  he  simpler  and  more  efficient  would  however  te  a maior 
de si  an  task. 


07.  The  exception  ►■andlinq  control  structure  will  permit  *hc 
user  to  cause  transfer  of  rontrol  ana  data  for  any  error  or 


“xcrrtion  situation  which  "iubt  occur  in  a proqrar;..  ....F 

Program  can  net  control  tor  anv  exception  F 

Parameters  can  be  passed  F 

Can  aet  out  of  any  level  of  a nest  of  control  F 

Can  handle  the  exception  at  arv  level  control  F 


The  lanquaoe  has  no  such  facility. 

* moderate  to  major  char.oe  would  he  required. 


Gfl.  There  will  he  source  language  features  which  permit 
delov  on  anv  control  path  until  some  specified  time  or 
situation  has  occurred,  which  permit  specification  of  the 
relative  priorities  amonn  parallel  control  paths,  which  give 
access  to  real  time  clocks,  which  permit  asynchronous 
hardware  interrupts  to  he  trpated  as  any  other  exception 
situation. 


Priority  specification  . . . F 

Synchronisation  via  wait/enahle  operations  T 

wait  tor  end  of  real  time  interval  ...,f 

Wait  for  end  e*  simulated  time  interval  F 

Wait  for  hardware  interrupt  ..................................... P 

(Can  enable  and  disable  interrupts)  .............................  1 


There  is  no  afreet  prevision  for  specification  of  priorities  amend 
parallel  paths,  although  in  special  situations  the  counts  on  signal 
variables  could  be  used  to  control  priority.  The  WAIT  (p.  19S)  could  in 
principle  he  used  to  wait  for  a time  interval  or  a hardware  interrupt, 
hu*  th«re  is  rio  lannuaye-def inea  connection  between  SIGNAL  variables  and 
186).  (Tee  the  comments  on  exception  handling,  reuuirement 


r 
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In  t*-is  reviewer's  oririon,  the  parallel  processing  feature  of 
S 1 1 L f \ *-houlf1  be  totally  redesigned  --  a maior  task.  Just  making  the 
nodif  ico  t ions  explicitly  reouiren  here  would  he  of  moderate  difficulty. 
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hi.  The  source  lanouaqe  will  he  Tree  format  with  an  explicit 
statement  delimiter,  will  ellrw  the  use  of  mnemoni ca l ly 
significant  identifiers,  will  he  based  on  conventional  forms, 
•will  nave  a simple  unifor*  arid  easily  rarsed  arammar,  will 


not  'rovioe  uniaue  notations  fcr  sneciol  cases,  will  not 
oeroit  abbreviation  of  identifiers  or  key  xords,  and  will  hr 
syntactically  unamb i ouous  . ....I 

Free  format  with  statement  terminator  T 

rreponic  identifiers  possible  T 

Da s**d  cn  conventional  turns  T 

S i nr  1 2 uranmar  1 

ho  siecial  case  nrtations  ..........T 

No  abbreviations  of  identifiers  c>r  keywords  T 

■ inamt'i rucu s c, rammer  .T 


SPLM  has  a s t rai oht f orwa rd,  mostly  clean  syntax.  For  example.  If, 
VHILf,  UNTIL,  C A ?•  F , end  FOR  statements  must  have  a cor r rspondi no  eniino 
bracket  'r.u.,  FhhlF),  so  that  f F h I‘: . . . F N 0 r.  rackets  are  <jr  necessary  . 
For  the  most  part,  someone  unfamiliar  with  SPL/I  can  understand  nroorans 
in  t ht  lar.auane. 

nre  unfortunate  rule  is  that  a statement  may  have  only  one  label 
(p.  A.7);  thus  multiple  labels  must  be  written  LI:;  L2:;  Li:  statement. 


H?.  The  user  will  not  be  able  to  modify  the  source  language 
syntax.  Specifically,  no  will  not  he  able  to  modify  c.nentor 
hierarchies,  introduce  new  precedence  rules,  define  n**w  koy 
mrJ  forms  or  define  new  infix  operator  precedences. 


I 


There  are  no  such  facilities  ir  SPl  'I. 


H3.  The  syntax  of  source  lanouaoe  proorams  will  be 
com^osable  from  ».  character  set  suitable  for  publication 
purposes,  but  so  feature  of  the  l anoueoe  «*ill  be  inaccessible 
usiro  tbe  64  character  ASCII  rubset. 


SPL/I 

sequi  r «'"rer«t  H4 


w4.  Trie  l ancjuf.ge  definition  will  provide  the  formation  rules 
for  identifiers  ann  literals.  These  will  include  literals 
for  numbers  and  character  strinos  and  a break  character  for 
js*»  internal  to  identifiers  and  literals. 


^ r e a k character  exists  .......................... ................T 

(Literals  are  «.e  l f-i  dent  i f y i no  as  to  type)  ......................  T 

(Pit-strino  literals  for  any  tynr)  .............................. F 


The  SFL/I  break  character  for  identifiers  is  the  jnderserre  (p.  7). 
Literal*,  for  Doth  primitive  and  structured  types  are  se  l f -ident  i f yi  no  as 
to  tyi t (pp.  1C.fi,  111-113). 


HS.  There  will  be  no  continuation  ot  lexical  units  across 
lines,  but  there  uill  he  a *ay  to  include  obiect  characters 
suchasenri-of-linein  literal  strinos. 


. key  words  will  be  reserved,  will  he  very  few  in  number, 
will  te  informative,  and  will  not  he  usable  in  contexts  where 
an  identifier  can  he  used.  ....T 

There  are  v ? reserved  words,  which  seems  reasonable,  if  not 
outstandine  (n.  A-5). 


H7.  The  source  lanouaee  will  have  a sinqle  uniform  comment 
convention.  Comments  will  be  easily  distinguishable  from 
code,  ^ill  be  introoLced  by  i single  (or  possibly  two) 
lamuane  defined  characters,  will  permit  any  combination  of 
characters  to  appear,  will  te  able  to  appear  anywhere 
reasonable  in  Droor ?ms , will  automatically  terminate  at 
ena-of-linr  if  not  otherwise  terminatro,  and  will  not 
prohibit  automatic  reformattinn  nf  prmraTs. 

Uniform  coTTent  convention  

Look  different  from  code  
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bracketed  t y ore  or  two  characters  . ...T 

Car  rent  a in  any  characters  P 

Car  «>;.i je?r  anywhere  reasonable  T 

Terminated  by  the  end  of  the  line  'J 

Corratible  with  automatic  reformatting  T 

Comments  are  enclosed  in  s mure  brackets;  they  mpy  ccnt.sir  any 
characters,  except  that  included  sauare  brackets  must  bp  nested  <r.  52). 
They  Cnr  appear  between  ary  tokens  (p  . 3n)  . The  marital  ao«»s  rot  $ny 
whether  end  of  line  terminates  a comment;  it  seems  unlikely. 

A trivial  chance  would  be  required  to  fully  meet  this  requirement. 


Mb.  The  lannuaoe  will  rot  rerrrit  unmatched  parentheses  of 
any  kind.  ....1 

See  entire  syntax;  all  brackets  must  tr  in  pairs. 


h9.  There  will  be  a uniform  referrnt  notation.  ....T 

Fully  met.  See  pp.  Ilf  , 124-1 2f . 


Hi  l’ . ho  lannur-qe  defined  symbols  appearinc  in  the  same 
context  will  have  essentially  different  meaninos.  ....T 
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II.  There  will  he  ro  defaults  in  programs  which  affect  the 
•>r ji  ra."  loisic.  That  is,  decisions  which  affect  prooran.  loqic 
Mill  he  made  either  irrevocably  when  the  lanquaqe  is  defined 
or  fvc  licit  Iv  in  each  nronrarr.  ...,F 


FPL/T  is  full  cf  implementation  dependent  defaults  --  for  examnle, 
the  rsr  ]c  ard  precision  of  variables  fpp.  51-5?)  and  of  counters  on 
SIGNAL  variables  (r . 53),  ard  th«  association  of  hardware  signets  with 
si^ral  identifiers  <c.  1P6).  In  addition,  the  association  of  a system 
resource  i t h a resource  variahlr  arid  of  a software  siqnal  source  with  a 
sinnal  icentitier  are  mare  by  proarairmer  conventions  (p.  171#  ISfn). 

v"etinn  the  requirement  would  be  cf  at  least  nedi  uir-l  eve  l 
difficulty.  Not  only  ranue  declarations,  etc.,  would  he  required,  bu* 
also  the  ranqes  of  arithmetic  results  would  have  to  be  precisely  defined 
in  terms  of  the  r=nces  cf  their  rnerands. 


I e . refaults  will  be  trovideo  for  special  capabilities 
affect  inn  onlv  object  representation  and  other  properties 
which  the  programmer  does  not  knew  or  care  about.  Such 
defaults  will  always  mean  tlat  the  iroqrammer  does  not  care 
which  choice  is  made.  The  nrooraomer  will  be  able  to 


override  these  defaults  when  reeessarv.  ....ft 

Defaults  scecified  for  don't  care  casts  ......................... T 

Programmer  can  override  the  defaults  P 


Such  thims  as  data  representation,  parameter  class  (p.  dU) , 
storage  class  (:•.  <*)),  reentrarcy  fn.  ?t- 77),  and  closed  calls  are 
decide:  t>  default  if  left  unsper  i fieri.  Not  all  can  be  overridden  — in 
particular,  data  representation  nr  closed  calls. 

open  c^lls  would  not  be  nard  to  provide,  but  allowing  pronrammer 
control  over  data  representation  wruM  entail  at  least  a moderate  amount 
of  work. 


13.  The  user  will  be  able  to  associate  compile  time 
variacles  with  pro-7  rams.  These  will  include  variables  which 
specify  the  ohiect  commuter  model  and  other  asrects  of  the 
ohiert  machine  configuration. 
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SPl/I  has  no  such  facility. 

The  necessary  addition  would  be  fairly  easy,  if  done  minimally. 


14.  The  source  lannuacje  will  permit  the  use  cf  conditional 
statements  (®.n.,  case  statements)  dependent  on  the  object 
environment  and  other  compile  time  variables.  )n  such  cases 
the  conditional  will  be  evaluated  at  compile  time  and  only 
the  selected  path  will  be  compiled.  . ...f 


SF L / I has  no  such  facility. 

fhe  required  addition  would  not  be  trivial,  but  not  very  hard 
either. 


15.  The  source  lanouage  will  contain  a simple  clearly 
i (lent  i f i ab  le  base  or  kernrl  wfich  bouses  ell  the  power  of  the 
lancuaue.  To  the  extent  possible,  *hp  base  will  be  minimal 
with  each  feature  providinc  a sinale  unique  cacability  not 
otherwise  duplicated  in  the  base.  The  choice  of  the  base 
will  net  detract  from  the  efficiency,  safety,  or 

under  st  andab  i l i t y of  the  lanouane.  ....F 


The  whole  lanouaoe  is  a unit;  there  is  no  kernel  on  which  the  rest 
is  bared. 

Tt  define  and  extract  such  a kernel  would  te  a major  channe. 


16.  L«nouaqe  restrictions  which  are  dependent  only  on  the 
trf-n'lator  and  not  on  the  object  machine  will  be  specified 
explicitly  in  the  lanouaoe  definition.  ,...F 


The  maximum  numf^r  of  characters  in  a name  is  f art  of  the  language 
definition  (it  is  16  --  see  p.  16).  Limits  on  the  number  of  array 
dimensions,  the  size  of  each  (p.  65),  the  number  of  variables  (see, 
e.g.,  o.  175),  and  deoth  of  parentheses  nestino  in  expressions  ere  all 
i mp l emert at i on  dependent. 
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Tbt  Prtait  lor  c l sr  eci  f i cat  irn  should  oe  easy;  the  effects 
ewistir.,  ro^riler*  "iiht  net  te. 


I f.  L;-nrua<3e  restrictions  which  ore  inherently  'ienenfpnt 
onl>  on  the  object  erv  i rr.riTent  will  not  he  built  into  the 
u e ii«f  i ^ i t i on  rr  artv  tr-nslutor. 
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J1.  The  langunoe  and  its  translators  will  net  impose  run 
time  costs  tor  unneeded  or  unused  generality.  They  will  he 


canatle  of  producing  efficient  code  for  all  programs.  ....w 

no  “fficiency  cost  'for  unused  features  ...'* 

Ffticient  code  cam  be  producer-  for  all  features  .F' 


So"e  inefficiencies  in  SPLM  are: 

1.  The  direction  of  a r 0R  loor  is  dynamically  determined 
according  to  the  sign  of  the  value  of  the  PY  expression; 
this  is  unnecessary,  and  inefficient.  other  fop 
inefficiencies  are  mentioned  under  G 4. 

? . Pointed-t"  values  can  only  be  in  the  heap;  often  more 
efficient  storage  discipline  would  suffice,  but  SPL/1  ^oes 
not  orovide  for  them  for  these  objects  (p.  5r.  ) . 

f.  A scalar  actual  parameter  can  match  an  array  formal 
garameter  (n.  pll).  We  suspect  this  raises  the  cost  even 
for  the  passage  of  normal  arrays  as  parameters. 

4.  Thp  rules  for  GOTO  surrogates  cause  inefficiency. 

SPL/T  4oes  have  a side  effect  rule  which  allows  efficient  code,  and 
allows  declaration  of  no^-recur s i veness  for  procedures  (both  contrary  to 
the  Tinman). 

At  least  a moderate  effort  would  fe  required.  The  FOR  rules  would 
not  he  hard  to  chanoe,  but  providing  a choice  of  storage  discipline  for 
pointeri-to  values,  and  a good  se*  of  GOTO  surrogates  would  be  harder 
(unless  the  restrictions  on  GOTO  were  simply  removed,  as  we  believe  they 
should  be ) . 


J 2.  Any  optimizations  performed  by  the  translator  will  not 
change  the  effect  of  the  program.  ....'J 


This  is  not  a language  requirement. 


J3.  The  source  language  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  including  machine 
lamuaoe  code  insertions.  ....F 
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SF’I/I  has  no  such'  capability. 

l^r  necessary  channe  could  be  ®asy  to  moderately  ditficult, 
i ^eperdino  on  tf®  de jree  cf  integration  o*  SPL/T  code  and  machine  cole, 
the  protections  apainst  loss  of  optimization,  etc. 


J 4 . it  will  he  possible  within  the  source  lanouaoe  to 
soecifv  the  ooiect  presentation  rf  composite  data  structures. 
Tnese  descriptions  will  be  ortionnl  and  encapsulated  and  will 
be  distinct  Iro"  the  logical  oescrir:  lion.  The  user  will  be 
?,bf®  to  s~ecitv  the  tifna/sracr  trade-off  to  the  translator. 
If  rot  specified,  the  object  representation  will  be  optimal 


as  determined  by  the  translator.  ....F 

f near su l at ed  specification  of  rec resentat ion  possible  ....... ....F 

Space'tiTie  tradeoff  can  be  specified  ..f 


Sfl/I  has  no  such  capability 
» rocercte  to  major  chance  is  requires. 


J5.  Tr>e  proorammer  will  be  a^le  tc  specify  whether  calls  or. 
a routine  are  to  have  an  oren  or  closed  implementation.  An 
crer.  and  a closed  routine  of  the  same  description  wilt  have 


identical  semantics.  . . . . f 

Ooen/closed  properties  car  be  specified  ......................... T 

Open  and  closed  versions  have  the  same  semantics  ..........F 


SPL/1  has  p,n  such  facility;  all  procedures  are  closed, 
fi  moderate  chanoe  is  required. 


J 
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rxtraneous  Features 

we  recommend  that  the  followinq  features  of  SPL/I,  not  required  by 
the  Tinman,  be  ke<~t  : 

* CFLOAT  (complex)  type. 

* STRING  tyoe  (assuminn  that  the  Tinman  requires  only  a 
character  type,  not  a character  strinc  type). 

* SIGNAL,  PFSODRCF,  and  PROCFSS  types.  Althouoh  not 
explicitly  called  for  by  the  Tinman  as  types,  thev  are 
needed  in  the  SPL/1  reslitation  of  other  Tinmen 
requirements  (parallel  processing).  They  should  he 
redesigned . 

* Call  by  value  parameters. 

* Pit  string  literals. 


we  recommend  that  the  follcwinq  features  of  SPL/I,  not  required  by 
the  Tinman,  be  deleted: 

* FRAC  (fraction)  type.  The  use  of  this  type  is  not 

clear  and  it  can  probably  be  replaced  by  a fixed-point 

tyne . 

* PINT  (double  precision  irteqer)  type.  The 

functionality  obtaineo  with  this  type  can  be  assumed 
by  range  specifications  on  integer  tyre. 

* CFRAC  (complex  fraction)  and  PINT  (complex  inteoer) 

types.  These  appear  to  Ke  of  extremely  limited 

usefulness . 

* Array  slices. 


Jt  is  recommended  that  the  CFLOAT  type  be  retained  because  it  is  a 
numeric  type  and  the  user  should  be  able  to  use  the  numeric  operators 
with  data  of  that  type.  If,  however,  SPL/1  is  extended  to  permit 
extension  of  built-in  operators  to  user-defined  types  (which  a^p 
themselves  extensions  to  SPL/I),  then  CFLOAT  could  be  deleted  from  the 
base  lancuaqe. 


Surm?  r y 

fert  it?  the  fact  that  it  was  designed  lor  siqnal  processing 
.i;ip  l i cafi  •'ns , 5HL/I  is  a cene'ral  furpnse  language,  and  if  is  a fairly 
clean  "no , .-itn  fte  exception  of  the  parallel  processing  features.  The 
last  i»  i>  he  an  unfair  criticise,  because  we  have  seer  no  language  which 
nroyider.  all  necessary  mechanisms  for  parallel  processing  cleanly  and 
efficiently  — maybe  it  cannot  b«*  done  (and  therefore  should  not  be  a 
Tinman  rerui rement ) . Still,  we  felieve  it  could  be  oone  better  than  in 
SPl/T  . 

I r,  rpp  y resnrcts  Sf‘L/I  conforms  tc  the  spirit  of  ♦he  Tinman 
renuu>-fents;  for  example,  it  has: 

* Strom-  typ e-checkino,  without  froplicit  conversions. 

* powerful  data  structuring  tools  (without  discriminated 
union  or  alternate  record  structures,  however). 

* Support  for  parallel  processing. 

* Structured  control  rect’-nisr.s  (although  there  are  some 
problems  with  individual  mechanisms,  as  the  detailed 
evaluation  shows). 

* Variable  initialization. 

* Attention  to  serrrete  compilation. 

* Mecursive  rroceriures,  with  the  ability  to  de clare 
non- recur s i venes  s . 

* Pointer  variables,  in  a way  similar  to  Pascal  — i.e., 
a clean  way. 

* Consistent  treatment  of  structures.  For  example,  a 
function  result  can  be  structured,  and  structured 
literals  can  po  built. 


SWL/I  is  also  a reasonable-si zeo  (not  too  big),  fairlv  simple, 
language.  It  pays  For  this,  boweyer,  in  missino  features.  For  example, 
♦he  following  ere  not  provided: 

* Banye  and  precision  cr e c i f i ca t i on  for  variables. 

« Powersets,  end  enumeration  types  as  such. 

* union  of  tyres  ana  alternate  record  structures. 

* The  ability  tc  define  n»u  tyoes,  including  operations 
on  obiects  o*  the  type. 
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* Encapsulated  machine  code. 

* Control  over  representation  of  data  objects. 

* Dynamic  upper  array  bound,  or  lower  bound  different 
from  1 . 

* Fixed  point  tyne. 

* Identifiers  to  stand  for  constants. 

* Conditional  compilation. 


Cn  balance,  SPL/I  is  a much  cleaner,  more  readable,  simpler 
lanquage,  *han,  for  example,  CS-4.  It  even  has  two  very  important 
features  that  CS-4  does  not:  Recursive  procedures  and  pointers.  It  is 
missino  a number  of  features  in  CS-4,  but  most  of  these  are  provided  in 
such  an  awkward  way  in  CS-4  that  extending  SPl/I  would  probably  result 
in  a cleaner  lanquaae. 

On  the  other  hand,  we  see  little  rerson  to  chcse  SPL/1  instead  of 
Pascal  as  a basis  for  extension  to  meet  the  final  version  of  the  Tinman 
reaui rements.  The  chief  features  in  SPL/1  which  are  not  in  Pascal  are 
parallel  processing,  structured  function  results,  variable 
initialization,  and  multiole  storaoe  classes  — and  indeed,  all  but  the 
first  are  done  well.  However,  these  features  could  easily  he  add  to 
Pascal.  Pascal  has,  and  SPL/I  does  not,  powersets,  enumeration  tynes, 
ranges  of  values,  and  alternate  record  structures.  Pascal  also  has 
better  /more  efficient,  safer)  iteration  control  structures,  and  is 
probably  a smaller,  simpler  lanauaqe  (easier  to  read  and  compile)  than 
SPL/I.  In  addition,  rascal  is  ir.uch  tetter  known,  and  some  of  the  oest 
features  of  SPL/I  have  been  taken  directly  from  Pascal  (e.q.,  the  method 
of  providino  pointers). 

The  SPL/I  Language  Reference  Manual  is  fairly  good  --  it  is 
consistently  and  carefully  oroanized  and  defines  most  of  the  features  of 
the  language.  Ho-ever,  it  could  be  improved  creatly  by  the  addition  of 
more  interestinn  examples  (the  niven  examples  never  provide  the  answer 
to  a questionable  point  in  the  description),  the  insertion  of  more 
summary  descriptions  (as  it  is,  the  reader  often  has  to  refer  to  many 
different  pages  to  find  the  answer  to  a simple  question),  and  an 
expanded  index. 


